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Status of this Memo 


This memo provides information for the Internet community. It does 
not specify an Internet standard. Distribution of this memo is 
unlimited. 

Overview 


The Energy Sciences Network (ESnet) is a nation-wide computer data 
communications network managed and funded by the United States 
Department of Energy, Office of Energy Research (U.S. DOE/OER), for 
the purpose of supporting multiple program, open scientific research. 
ESnet is intended to facilitate remote access to major Energy 
Research (ER) scientific facilities, provide needed information 
dissemination among scientific collaborators throughout all ER 
programs, and provide widespread access to existing ER supercomputer 
facilities. 


Coordination of ER-wide network-related technical activities over the 
ESnet backbone is achieved through the ESnet Site Coordinating 
Committee (ESCC). This committee is comprised of one technical 
contact person from each backbone site, as well as some members of 
the ESnet management and networking staff. As the need for new 
levels of ESnet services arise, the ESCC typically creates task 
forces to investigate and research issues relating to these new 
services. Each task force usually results in a whitepaper which 
makes recommendations to the ESnet community on how these services 
should be deployed to meet the mission of DOE/OER. 


This RFC is a near verbatim copy of the whitepaper produced by the 
ESnet Site Coordinating Committee’s X.500/X.400 Task Force. 
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Status of this Document 


This document makes recommendations for the Phase I deployment of OSI 
Directory Services and OSI Message Handling Services within the ESnet 
Community. This document is available via anonymous FTP on the ESnet 
Information Server (nic.es.net, 128.55.32.3) in the directory 
[ANONYMOUS.ESNET-DOC] in the file ESNET-X500-X400-VERSION-1-1.TXT. 
The distribution of this document is unlimited. 
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1. Introduction 
1.1. Abstract and Introduction 


This document recommends an initial approach for the Phase I 
deployment of OSI Directory Services (X.500) and OSI Message Handling 
Services (X.400) within the ESnet community. It is anticipated that 
directly connected ESnet backbone sites will participate and follow 
the suggestions set forth in this document. 


Section 7 of the "ESnet Program Plan" (DOE/OER-0486T, dated March 
1991) cites the need for further research and investigation in the 
areas of electronic mail and directory services. The ESCC 
X.500/X.400 Task Force was created to address this need. 
Additionally, the task force is addressing the issues of a 
coordinated, interoperable deployment of OSI Directory Services and 
OSI Message Handling within the entire ESnet community. Since only a 
small subset of this community is actively pursuing these avenues, 
considerable effort must be made to establish the necessary "base" to 
build upon. If directly connected ESnet sites participate in these 
Services, a consistent transition path will be ensured and the 
services provided will be mutually valuable and useful. 


X.500 and X.400 are continuously evolving standards, and are 
typically updated every four years. U.S. GOSIP (Government OSI 
Profile) Requirements are updated to define additional functionality 
as needed by the U.S. Federal Government, usually every two years. 
As the X.500 and X.400 standards evolve and U.S. GOSIP Requirements 
are extended, consideration must be given as to the effect this may 
have on these existing services in the ESnet community. At these 
cross-roads, or when a sizeable increase in service functionality is 
desired, another "phase of deployment" may be in order. In this 
sense, there isn't a specific "final phase" goal, but rather several 
new releases (updates) to the level of existing services. 


1.2. Structure of this Document 


X.500 is presented first. The issues of DSA (Directory Service 
Agent) deployment, DSA registration, naming schema, involvement in 
the PSI White Pages Pilot Project, recommended object classes, 
recommended attribute types, information security, search 
optimization, user friendly naming and update frequency are 
addressed. 


In the area of X.400, issues relating to MTA (Message Transfer Agent) 
deployment, ESnet X.400 well-known entry points, ESnet backbone site 
X.400 well-known entry points, MTA registration, naming hierarchy, 
PRMD peering, bidirectional X.400-SMTP relaying and 
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private/commercial X.400 routing are discussed. 


Finally, the issues in name registration with ANSI (American National 
Standards Institute), GSA (General Services Administration) and the 
U.S. Department of Commerce, Patent and Trademark Office (PTO) are 
discussed. 


2. X.500 - OSI Directory Services 
2.1. Brief Tutorial 


X.500 is a CCITT/ISO standard which defines a global solution for the 
distribution and retrieval of information (directory service). The 
X.500 standard includes the following characteristics:  decentralized 
management, powerful searching capabilities, a single global 
namespace, and a structured framework for the storage of information. 
The 1988 version of the X.500 standard specifies four models to 
define the Directory Service: the Information Model, the Functional 
Model, the Organizational Model and the Security Model. As is the 
nature of International standards, work continues on the 1992 X.500 
standard agreements. 


The Information Model specifies how information is defined in the 
directory. The Directory holds information objects, which contain 
information about "interesting" objects in the real-world. These 
objects are modeled as entries in an information base, the Directory 
Information Base (DIB). Each entry contains information about one 
object: ie, a person, a network, or an organization. An entry is 
constructed from a set of attributes each of which holds a single 
piece of information about the object. For example, to build an 
entry for a person the attributes might include "surname", 
"telephoneNumber", "postalAddress", "rfc822Mailbox" (SMTP mail 
address), "mhsORAddresses" (X.400 mail address) and 
"facsimileTelephoneNumber". Each attribute has an attribute syntax 
which describes the data that the attribute contains, for example, an 
alphanumeric string or photo data. The OSI Directory is extensible 
in that it defines several common types of objects and attributes and 
allows the definition of new ones as new applications are developed 
that make use of the Directory. Directory entries are arranged in a 


hierarchical structure, the Directory Information Tree (DIT). It is 
this structure which is used to uniquely name entries. The name of 
an entry is its Distinguished Name (DN). It is formed by taking the 


DN of the parent's entry, and adding the the Relative Distinguished 
Name (RDN) of the entry. Along the path, the RDNs are collected, 
each naming an arc in the path. Therefore, a DN for an entry is 
built by tracing the path from the root of the DIT to the entry. 


The Functional Model defines how the information is stored in the 
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directory, and how users access the information. There are two 
components of this model: the Directory User Agent (DUA), an 
application-process which interacts with the Directory on behalf of 
the user, and the Directory System Agent (DSA), which holds a 
particular subset of the Directory Information Tree and provides an 
access point to the Directory for a DUA. 


The Organizational Model of the OSI Directory describes the service 
in terms of the policy defined between entities and the information 
they hold. The model defines how portions of the DIT map onto DSAs. 
A Directory Management Domain (DMD) consists of one or more DSAs, 
which collectively hold and manage a portion of the DIT. 


The Security Model defines two types of security for Directory data: 
Simple Authentication (using passwords) and Strong Authentication 
(using cryptographic keys). Authentication techniques are invoked 
when a user or process attempts a Directory operation through a DUA. 


2.2. Participation in the PSI White Pages Pilot Project 


The PSI White Pages Pilot Project is currently the most well- 
established X.500 pilot project within the United States. For the 
country-US portion of the DIT, PSI currently has over 80 organization 
names registered. Of these, several are ESnet-related. 


The PSI White Pages Pilot Project is also connected to the Pilot 
International Directory Service, PARADISE. This pilot project 
interconnects X.500 Directory Services between Australia, Austria, 
Belgium, Canada, Denmark, Finland, France, Germany, Greece, Iceland, 
Ireland, Israel, Italy, Japan, Luxembourg, Netherlands, New Zealand, 
Norway, Portugal, Spain, Sweden, Switzerland, United Kingdom and 
Yugoslavia. The combined totals for all of these countries 
(including the United States) as of December 1991 are: 


DSAs: 301 
Organizations: 2,132 
White Pages Entries: 581,104 


Considering the large degree of national, and international, 
connectivity within the PSI White Pages Pilot Project, it is 
recommended that directly connected ESnet backbone sites join this 
pilot project. 


2.3. Recommended X.500 Implementation 
Interoperability testing has not been performed on most X.500 


implementations. Further, some X.500 functions are not mature 
standards and are often added by implementors as noninteroperable 
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extensions. 


To ensure interoperability for the entire ESnet community, the 
University College London's publicly available X.500 implementation 
(QUIPU) is recommended. This product is known to run on several 
UNIX-derivative platforms, operates over CLNS and RFC-1006 (with 
RFC-1006 being the currently recommended stack), and is currently in 
wide-spread use around the United States and Europe, including 
several ESnet backbone sites. 


Appendix C contains information on how to obtain QUIPU. 


A later phase deployment of X.500 services within the ESnet community 
will recommend products (either commercial or public domain) which 
pass conformance and interoperability tests. 


2.4. Naming Structure 


As participants in the PSI White Pages Pilot Project, ESnet backbone 
Sites will align with the naming structure used by the Pilot. This 
structure is based upon a naming scheme for the US portion of the DIT 
developed by the North American Directory Forum (NADF) and documented 
in RFC-1255. Using this scheme, an organization with national 
standing would be listed directly under the US node in the global 
DIT. Organizations chartered by the U.S. Congress as well as 
organizations who have alphanumeric nameforms registered with ANSI 
are said to have national standing. Therefore, a backbone site which 
is a national laboratory would be listed under country=US: 


@c=US@o=Lawrence Livermore National Laboratory 

As would a site with an ANSI-registered organization name: 
@c=US@o=National Energy Research Supercomputer Center 
A university would be listed below the state in which it is located: 
@c=US@st=Florida@o=Florida State University 
And a commercial entity would be listed under the city or state in 
which it is doing business, or "Doing Business As", depending upon 
where its DBA is registered: 
@c=US@st=California@o=General Atomics 
(or) 


@c=US@st=California@l=San Diego@o=General Atomics 


A list of the current ESnet backbone sites, and their locations, is 
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provided in Appendix E. 


Directly connected ESnet backbone sites will be responsible for 
administering objects which reside below their respective portions of 
the DIT. Essentially, they must provide their own "Name Registration 
Authority". Although this may appear as an arduous task, it is 
nothing more than the establishment of a procedure for naming, which 
ensures that duplicate entries do not occur at the same level within 
a sub-tree of the DIT. For example, the Name Registration Authority 
for MIT could create an Organizational Unit named "Computer Science". 
This would appear in the DIT as: 


@c=US@st=Massachusetts@o=MIT@ou=Computer Science 


Similarly, all other names created under the 
"@c=US@st=Massachusetts@o=MIT" portion of the DIT would be 
administered by the same MIT Name Registration Authority. This 
ensures that every Organizational Unit under 
"@c=US@st=Massachusetts@o=MIT" is unique. By default, each ESnet 
Site Coordinator is assumed to be the Name Registration Official for 
their respective site. If an ESnet Site Coordinator does not wish to 
act in this capacity, they may designate another individual, at their 
Site, as the Name Registration Official. 


2.4.1. Implications of the Adoption of RFC-1255 by PSI 


The North American Directory Forum (NADF) is comprised of commercial 
vendors positioning themselves to offer commercial X.500 Directory 
Services. The NADF has produced several documents since its 
formation. The ones of notable interest are those which define the 
structure and naming rules for the commercially operated DIT under 
country=US. Specifically, for an Organization to exist directly 
under c-US, it must be an organization with national-standing. From 
pages 12-13 of RFC-1255, national-standing is defined in the 
following way: 


"An organization is said to have national-standing if it is 
chartered (created and named) by the U.S. Congress. An example 
of such an organization might be a national laboratory. There 
is no other entity which is empowered by government to confer 
national-standing on organizations. However, ANSI maintains an 
alphanumeric nameform registration of organizations, and this 
will be used as the public directory service basis for 
conferring national-standing on private organizations." 


Thus, it appears that National Laboratories (e.g. LBL, LLNL) are 


considered organizations with national-standing. However, those 
ESnet backbone sites which are not National Laboratories may wish to 
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register with ANSI to have their organization list directly under 
c=US, but only if this is what they desire. It is important to note 
that NADF is not a registration authority, but a group of service 
providers defining a set of rules for information sharing and mutual 
interoperability in a commercial environment. 


For further information on registering with ANSI, GSA or the U.S. 
Patent and Trademark office, refer to Section 4 of this document. 
For more information on PSI, refer to Appendix A. 


2.4.2. Universities and Commercial Entities 


Several of the ESnet backbone sites are not National Laboratories 
(e.g. CIT, FSU, GA, ISU, MIT, NYU, UCLA and UTA). Typically, at 
these sites, a small collection of researchers are involved in 
performing DOE/OER funded research. Thus, this set of researchers at 
a given site may not adequately represent the total X.500 community 
at their facility. Additionally, ESnet Site Coordinators at these 
facilities may not be authorized to act as the Name Registration 
Official for their site. So the question is, how do these sites 
participate in the recommended Phase I deployment of ESnet X.500 
services. There are two possible solutions for this dilemma: 


1. If the site is not currently operating an X.500 DSA, the ESnet 
Site Coordinator may be able to establish and administer a 
DSA to master the DOE/OER portion of the site’s local DIT, 
e.g. "@c=US@st=<st>@o=<site>@ou=Physics". Before attempting 
this action, it would be prudent for the Site Coordinator to 
notify or seek approval from some responsible entity. At such 
time that the site wishes to manage its own organization 
within the X.500 DIT, the ESnet Site Coordinator would have to 
make arrangements to put option 2 into effect. 


2. If the site is currently operating an X.500 DSA, the ESnet 
Site Coordinator may be able to work out an agreement with the 
current DSA administrator to administer a portion of the 
site’s local DIT which would represent the DOE/OER community 
at that site. For example, if the site were already 
administering the organization "@c=US@st= 
Massachusetts@o=Massachusetts Institute of Technology", the 
ESnet Site Coordinator might then be able to administer the 
organizational unit "@c=US@st=Massachusetts@o=Massachusetts 
Institute of Technology@ ou=Physics". 


2.4.3. Naming Structure Below the o=<site> Level 


The structure of the subtree below the organization’s node in the DIT 
is a matter for the local organization to decide. A site’s DSA 
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manager will probably want to enlist input from others within the 
organization before deciding how to structure the local DIT. 


Some organizations currently participating in the Pilot have 
established a simple structure, choosing to limit the number of 
organizational units and levels of hierarchy. Often this is done in 
order to optimize search performance. This approach has the added 
benefit of insulating the local DIT from administrative restructuring 
within the organization. Others have chosen to closely model their 
organization's departmental structure. Often this approach seems 
more natural and can enhance the information obtained from browsing 
the Directory. 


Below are experiences from current DSA managers, describing the way 
they structured their local DIT and the reasons for doing so. A site 
may find this information helpful in determining how to structure 
their local DIT. Ultimately this decision will depend upon the needs 
of the local organization and expectations of Directory usage. 


Valdis Kletnieks of the Virginia Polytechnic Institute: 


"For Virginia Tech, it turned out to be a reasonably 
straightforward process. Basically, the University is 
organized on a College/Department basis. We decided to model 
that "real" structure in the DIT for two major reasons: 


"(a) It duplicates the way we do business, so interfacing the 
X.500 directory with the "real world" is easier. 


"(b) With 600+ departmental units and 11,000+ people (to be 
30,000+ once we add students), a "zero" (everybody at top) or 
"one" deep (600 departments at top) arrangement just didn't 
hack it - it was deemed necessary that you be able to do a 
some 120 or 140 county office entries under the Extension 
Service, it's a BIT unwieldy there). However, with some 20 
college-level entries at the top, and the "average" college 
having 30 departments, and the "average" department being from 
10 to 40 people, it works out pretty well." 


Jeff Tannehill of Duke University: 
"Our DIT is flat. We get the entire database of people at Duke 
from Tel-Com and just put everyone directly under "O-Duke 
University". 
"Actually, there is an exception, when the DSA was first set up 


and we had not received a database yet, I configured the DIT to 
include "OU=Computer Science", under which myself and one other 
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System Administrator have entries. Upon getting the database 
for everyone else I decided not to attempt to separate the 
people in the database into multiple ou's." 


Joe Carlson of Lawrence Livermore National Laboratory: 


"We tried both flat (actually all under the same OU) and 
splitting based on internal department name and ended up with 
flat. Our primary reason was load and search times, which were 
2-3 times faster for flat organization." 


Paul Mauvais of Portland State University: 


"We originally set up our DIT by simply loading our campus 
phone book into one level down from the top (e.g. OU-Faculty 
and Staff, OU-Students, OU-Computing Services). 


"I'd love to have an easy way to convert our flat faculty and 
staff area into departments and colleges, but the time to 
convert the data into the separate OU's is probably more than I 
have right now." 


Mohamed Ellozy of Dana-Farber Cancer Institute: 
"Here we have a phone database that includes department, so we 


got the ou's with no effort. We thus never went the flat space 
way." 


Dan Moline of TRW: 


"Well - we're still in the process of defining our DIT. TRW 
comes under the international companies DBA. Our part under 
the PSI White Pages Pilot defines the DIT for our space and 
defense organization here in Redondo Beach (however, I 
organized the structure to adhere to TRW corporate). We input 
from our manpower DB for our S&D personnel. We're trying to 
get corporate's DB for possible input. 


"However, arranging your DIT by organizations (at least for 
corps) presents a problem; things are always being reorganized! 
We were DSO now we're SSO!!! We still have some of our old 
domain name for DNS tied to organizations that have not existed 
for years! 


"So we are currently redesigning our DIT to try to fit NADF 175 


(something more geographically). Our reasoning was that 
organizations may change but buildings and localities do not." 
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Ruth Lang of SRI: 


"There has been no SRI-wide policy or decision to participate 
in the PSI White Pages Pilot. @c=US@O=SRI International 
supports the information for one OU only (i.e., a local policy 
and decision). In order to not give the false impression that 
all SRI information was contained under this O-SRI 
International, I used OU=Network Information Systems Center. 

If I were to structure the DIT for all of SRI, I'm sure that my 
thinking would yield a much different structure." 


Russ Wright of Lawrence Berkeley Laboratory: 


"Since we don't have much organizational information in current 
staff database, I have to stick to a fairly flat structure. I 
have two OUs. One is for permanent staff, the other is for 
guests (there is a flag in our database that is set for 
guests). 


"I may add an additional level of OUs to our current structure. 
The top level would contain different 'types' of information. 
For example, one OU may be 'Personnel', another may be called 
publications). Staff and Guests would reside under the 
Personnel OU." 


Peter Yee of NASA Ames: 


"I broke up my DIT at the NASA Center level. NASA is made of 
nearly 20 Centers and Facilities. The decision to break up at 
this level was driven by several factors: 


"1. Control of the local portion of the DIT should reside with 
the Center in question, particularly since the Center probably 
supplies the data in question and controls the matching DSA. 


"2. Each Center ranges in size from 1,000 to 16,000 persons. 
This seems to be the range that works well on moderate sized 
UNIX servers. Smaller would be a waste, larger would require 
too much memory. 


"3. Representatives from several Centers have contacted me 
asking if they could run their own DSAs so that they can 
experiment with X.500. Thus the relevant DSA needs to be under 


their control." 
2.5. Information Stored in X.500 


The Phase I deployment of X.500 should be limited to "white pages"- 


ESCC X.500/X.400 Task Force [Page 13] 


RFC 1330 X.500 and X.400 Plans for ESnet May 1992 


type information about people. Other types of objects can be added 
in later Phases, or added dynamically as the need arises. 


To make X.500 truly useful to the ESnet community as a White Pages 
Service, it is recommended that the following minimum information 
should be stored in the X.500 database: 


Information ASN.1 Attribute Type Example 

Locator Info commonName Allen Sturtevant 
surname Sturtevant 
postalAddress LLNL 


P.O. Box 5509, L-561 

Livermore, CA 94551 
telephoneNumber +1 510 422 8266 
facsimileTelephoneNumber +1 510 422 0435 


E-Mail Info rfc822Mailbox Sturtevant@es.net 
mhsORAddresses /PN=Allen Sturtevant /O=NERSC/ 
/PRMD-ESnet/ADMD- /C=US/ 
otherMailbox DECnet: ESNIC::APS 


The above list of attributes comprises a minimum set which is 
recommended for a person’s entry. However, you may chose to omit 
some attributes for reasons of privacy or legality. Note that the 
X.500 standard requires that the surname and commonName attributes be 
present. If an individual’s phone number and/or address cannot be 
provided, they should be replaced by the site’s "Information Phone 
Number" and postal address to allow some means of contacting the 
person. 


2.5.1. Information Security 


It is understood that placing this type of information in X.500 is 
equivalent to putting the "Company Phone Book" on-line in the 


Internet. Different sites may treat this information differently. 
Some may view it as confidential, while others may view this data as 
open to the public. In any case, it was recommended that ESnet sites 


discuss the implications with their respective legal departments 
before actually making their information openly available. There 
currently exists minimal access control in several X.500 
implementations. 


2.6. Accessing the X.500 Directory Service 
The PSI White Pages Pilot Project software provides numerous 


interfaces to the information in the X.500 Directory. Non- 
interactive access mechanisms (e.g. WHOIS, FINGER and Electronic 
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Mail) make use of capabilities or services which already reside on 
many workstations and hosts. Such hosts could immediately take 
advantage of the X.500 service with no additional software or 
reconfiguration needed. However, since these methods are non- 
interactive, they only provide a way to search for and read 
information in the Directory but no way to modify information. 


2.6.1. Directory Service via WHOIS 


The Pilot Project software allows you to configure the X.500 
Directory service to be made available via a network port offering an 
emulation of the SRI-NIC WHOIS service.  UNIX-based hosts and VMS 
hosts running Multinet typically come configured with the WHOIS 
service. Users at their workstations would then be able to issue a 
simple WHOIS command to a known host running a DSA to retrieve 
information about colleagues at their site or at other ESnet sites. 
For example, the command: 


whois -h wp.lbl.gov wright 


will return information about Russ Wright at Lawrence Berkeley Lab. 
It is recommended that all sites which bring up such a service, 
should provide an alias name for the host running their DSA of the 
form «wp.site.domain» for consistency within the ESnet community. 


2.6.2. Directory Service via Electronic Mail 


The Pilot Project software also allows the X.500 Directory service to 
be made available via electronic mail. A user who sends an 
electronic mail message to a known host running a DSA containing a 
WHOIS-like command on the subject line, would then receive a return 
mail message containing the results of their query. 


2.6.3. Directory Service via FINGER 


The X.500 Directory service could also be made available via the 
FINGER service. Although this access method does not come with the 
PSI Pilot Project software, several sites have already implemented a 
FINGER interface to the X.500 Directory. For ease of use and 
consistency, a single FINGER interface should be selected, then 
individual implementations within the ESnet community should conform 
to this interface. 


2.6.4. Directory Service via Specialized Applications 
Many X.500 Directory User Agents (DUAs) are widely available. Some 


of these come with the PSI Pilot Project software. Other DUAs, which 
have been developed by third parties to fit into the pilot software, 


ESCC X.500/X.400 Task Force [Page 15] 


RFC 1330 X.500 and X.400 Plans for ESnet May 1992 


2. 


2a 


are publicly available. These user agents support interactive access 
to the X.500 Directory allowing browsing, searching, listing and 
modifying data in the Directory. However, in most cases, use of 
these DUAs requires the Pilot Project software be installed on the 
host system. Only a few of these DUAs and their capabilities are 
described below. 


o DISH - A User Agent which provides a textual interface to the 
X.500 Directory. It gives full access to all elements of the 
Directory Access Protocol (DAP) and as such may be complex for 
novice users. DISH is most useful to the DSA administrator. 


o FRED - A User Agent which has been optimized for "white pages" 
types of queries. The FRED program is meant to be similar to 
the WHOIS network service. FRED supports reading, searching, 
and modifying information in the X.500 Directory. 


o POD - An X-windows based User Agent intended for novice users. 
POD relies heavily on the concept of the user "navigating" 
around the DIT. Pod supports reading and searching. There are 
no facilities to add entries or to modify the RDNs of entries, 
though most other entry modifications are allowed. 


6.5. Directory Service from PCs and MACs 


Smaller workstations and personal computers lack the computing power 
or necessary software to implement a full OSI protocol stack. Asa 
consequence, several "light-weight" protocols have been developed 
whereby the DAP runs on a capable workstation and exports a simpler 
interface to other end-systems. One such "light weight" protocol, 
the Directory Assistance Service (DAS), is incorporated in the PSI 
Pilot Project software. Another "light weight" protocol, DIXIE, was 
developed at the University of Michigan.  Publicly available User 
Agents for both the MAC and PC have been developed using the DA- 
service and the DIXIE protocol. So long as you have the Pilot 
Project software running on one host, you can provide these User 
Agents on many end-systems without having to install the Pilot 
Software on all those end-systems. 


For further information about available Directory User Agents, see 
RFC-1292, "Catalog of Available X.500 Implementations". 


7. Services Provided by ESnet 


Currently, there are several ESnet backbone sites which are operating 
their own DSAs within the PSI White Pages Pilot Project. It is 
anticipated that directly connected ESnet backbone sites will 
eventually install and operate their own X.500 DSAs. In the interim, 
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ESnet will provide complete support for ESnet backbone sites which 
presently do not have the time, expertise or equipment to establish 
X.500 services. The mechanism for doing this is described in Section 
2.7.5 below. Additionally, ESnet will provide a variety of services 
in support of the entire X.500 community. These are also described 
in the following sections. 


2.7.1. X.500 Operations Mailing List 


ESnet maintains a mailing list for the discussion of relevant X.500 
topics. This mailing list provides a means for sharing information, 
experiences, and expertise about X.500 in the ESnet community. New 
sites joining the ESnet X.500 community will be announced on the 
mailing list. New DSA administrators will be able to solicit help 
from more experienced administrators. When a site brings up a new 
X.500 DSA, the DSA manager should notify the ESnet DSA manager so as 
to ensure they are promptly added to the mailing list. 


General discussion: x500-ops@es.net 
To subscribe: x500-ops-request@es.net 


2.7.2. Accessing the X.500 Directory 


ESnet has made the X.500 service openly available to the entire ESnet 
community via each of the access methods described in Section 2.6 
above. Host WP.ES.NET provides TELNET access, FINGER and WHOIS 
emulations, querying via electronic mail, as well as remote access 
via light-weight protocols. By making these services widely 
available, we hope to acquaint more users with the features and 
capabilities of X.500. 


To try out some of the X.500 User Agents, simply TELNET to WP.ES.NET 
and login as user "fred"; no password is required. You have the 
choice of running the Fred or Pod User Agents. Fred provides a 
command line interface while Pod provides an X-windows based 
interface. You can browse through the global X.500 DIT, search for 
persons in various organizations, and even modify your own entry if 
you have one. 


Host WP.ES.NET also provides access to the X.500 Directory via 
emulations of the FINGER and WHOIS utilities. These interfaces 
support a user-friendly-naming (UFN) scheme that simplifies the 
syntax necessary to search for persons in other organizations. The 
following WHOIS command lines illustrate searching for persons at 
various ESnet sites, utilizing the UFN syntax (similar FINGER command 
lines could also be constructed): 
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whois -h wp.es.net leighton,nersc 
whois -h wp.es.net servey,doe 

whois -h wp.es.net logg,slac 

whois -h wp.es.net "russ wright",lbl 


For further information about User Friendly Naming, see Steve 
Hardcastle-Kille's working document titled, "Using the OSI Directory 
to Achieve User Friendly Naming". 


2.7.3. Backbone Site Aliases 


As ESnet backbone sites join the X.500 pilot, their organizations’ 
entries will be placed in various parts of the DIT. For example, 
National Laboratories will be placed directly under the c-US portion 
of the DIT, while universities and commercial entities will most 
likely be placed under localities, such as states or cities. 


In order to facilitate searching for the ESnet community as a whole, 
ESnet backbone sites will also be listed as organizational units 
under the node "@c=US@o=Energy Sciences Network". These entries will 
actually be aliases which point to the site's "real" organizational 
entry. Therefore, ESnet backbone sites will be listed in two 
different places in the DIT and one could search for them in either 
location. 


2.7.4. Multiprotocol Stack Support 


OSI applications currently run over many different transport/network 
protocols, a factor which hinders communication between OSI end 
nodes. In order to facilitate communication, the ISODE may be 
configured at compile time to support any combination of the 
following stacks: 


RFC-1006 over TCP/IP 


TPO over X.25 

TPO over X.25 (84) 

TPO over the TPO-bridge 
TP4 over CLNP 


Within the ESnet community, the stacks of interest are RFC-1006 over 
TCP/IP, TP4 over CLNP, and TPO over X.25. If a backbone site’s DSA 
is not running over all three of these stacks, it may eventually 
receive referrals to a DSA that it can not connect to directly, so 
the operation can not proceed. Since the ESnet DSAs will be 
configured to operate over all of the "stacks of interest," they can 
serve as relay DSAs between site DSAs that do not have direct 
connectivity. The site's DSA manager will need to contact the ESnet 
DSA manager to arrange for this relaying to occur.  Backbone sites 
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will be encouraged to eventually provide as many of the three stacks 
of interest as possible. 


2.7.5. Managing a Site's X.500 Information 


For sites which do not initially wish to operate their own DSA, 
ESnet's DSA will master their site's portion of the DIT, enabling the 
site to join the PSI Pilot Project and the ESnet X.500 community. In 
order to accomplish this, the site must provide the ESnet DSA manager 
with information about the people to be included in the X.500 
Directory. This information can usually be obtained from your Site's 
Personnel Database. 


ESnet will only maintain a limited amount of information on behalf of 
each person to be represented in the Directory. The attribute types 
listed in the table in Section 2.5 show the maximum amount of 
information which the ESnet DSA will support for a person's entry in 
the Directory. This set of attribute types is a small subset of the 
attribute types offered by the PSI Pilot Project software. 

Therefore, if a site wishes to include additional attribute types, 
they should consider installing and operating their own DSA. 


The format of the information to be provided to the ESnet DSA manager 
is as follows: the data should be contained in a flat, ASCII text 
file, one record (line) per person, with a specified delimiter 
Separating the fields of the record. More detailed information and a 
sample of a site-supplied data file can be found in Appendix D. 


2.7.5.1. Open Availability of Site Information 


Although the PSI Pilot Project allows you to control who may access 
Directory objects and their attributes, any information you provide 
about persons at your site to be stored in the ESnet DSA will be 
considered world readable. This policy is necessary in order to 
minimize the administrative cost of managing potentially many 
organizational objects within the ESnet DSA. If your site decides 
that it does not wish to have certain information about its employees 
publicly known (e.g. work telephone number) then you should not 
provide this information to the ESnet DSA manager or you should 
consider installing and administering your own DSA. 


2.7.5.2. Access Methods for Local Users 


Backbone sites which choose the option of having the ESnet DSA master 
their organization's X.500 information should make the availability 
of the X.500 service known to their local users. All of the methods 
described in Section 2.7.2 are available for use, but none of these 
methods will assume the query is relative to the local site. 
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To facilitate querying relative to the local environment, the site 
will need to make one host available to run the emulation of the 
FINGER service. Although the resulting query will ultimately be 
directed to the remote ESnet DSA, the search will appear to be local 
to the users at that site. For example, a user on a workstation at 
site XYZ could type the following, omitting their local domain name 
as this is implied: 


finger jones@wp 
This will retrieve information about user Jones at site XYZ (wp is 
the name or alias of a host at site XYZ, i.e. wp.XYZ.GOV). The site 
coordinator will need to contact the ESnet DSA manager to arrange the 
set up for this service. 


2.7.5.3. Limitations of Using ESnet Services 


Since the ESnet DSA will potentially be mastering information on 
behalf of numerous backbone sites, limits will need to be placed on 


the volume of site information stored in the ESnet DSAs. These are 

enforced to ensure DSA responsiveness, as well as to reduce 

administrative maintenance. The limits are: 
Item Maximum Limit 
X.500 Organizations 1 
Organizational Units 50 
Organizational Unit Depth 3 
Object Entries 5,000 
Update Frequency 1 Month 
Aliases n/a 
Object/Attribute Access Control n/a 


One week before each monthly update cycle, a message will be sent on 
the x500-ops@es.net mailer to remind the sites that an update cycle 
is approaching. If no changes are required to the site information, 
the reminder message can be ignored and the existing version of this 
information will be used. If the information is to be updated, a 
complete replacement of all information must be supplied to the ESnet 
DSA manager before the next update cycle. More detailed information 
and a sample of a site-supplied data file can be found in Appendix D. 


2.8. ESnet Running a Level-0 DSA for c=US 


For ESnet to provide high quality X.500 services to the ESnet 
community, the ESnet DSAs must operate as Level-0 (first level) DSAs. 
It is currently planned that these DSAs will act as slave, Level-0 
DSAs to PSI's master, Level-0 DSAs. Once the ESnet DSAs are in 
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production service, it is recommended that directly connected ESnet 
backbone sites operating their own X.500 DSAs configure them with one 
of the ESnet DSAs as their parent DSA. This provides several 
advantages to the ESnet community: 


1. The ESnet DSAs will be monitored by the NERSC’s 24-hour 
Operations Staff. Additionally, ESnet plans to deploy two 
(2) DSAs in geographically disperse locations to ensure 
reliability and availability. 


2. All queries to Level-0 DSAs remain within the ESnet high-speed 


backbone. 

3. If network connectivity is lost to all external Level-0 DSAs, 
X.500 Level-0 connectivity will still exist within the ESnet 
backbone. 


2.9. X.500 Registration Requirements 


X.500 organization names must be nationally unique if they appear 
directly below the c-US level in the DIT structure.  Nationally 
unique names must be registered through an appropriate registration 
authority, i.e., one which grants nationally unique names. 


X.500 organizational unit names need to be unique relative to the 
node directly superior to them in the DIT. Registration of these 
names should be conducted through the "owner" of the superior node. 


The registration of X.500 names below the organization level are 
usually a local matter. However, all siblings under a given node in 
the DIT must have unique RDNs. 


See Section 4 for a more complete description of OSI registration 
issues and procedures. 


2.10. Future X.500 Issues to be Considered 

2.10.1.  ADDMDS Interoperating with PRDMDS 
This is a problem which currently does not have an answer. The issue 
of Administrative Directory Management Domains (ADDMDs) interacting 
with Private Directory Management Domains (PRDMDs) is just beginning 
to be investigated by several groups interested in solving this 


problem. 


2.10.2. X.400 Interaction with X.500 


The current level of understanding is that X.400 can benefit from the 
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use of X.500 in two ways: 

1. Lookup of message recipient information. 

2. Lookup of message routing information. 

X.400 technology and products, as they stand today, do not support 
both of these features in a fully integrated fashion across multiple 
vendors. As the standards and technology evolve, consideration will 
have to be given in applying these new functions to the production 


ESnet X.500/X.400 services environment. 


2.10.3. Use of X.500 for NIC Information 


Work is currently being performed in the IETF to place NIC 
information on-line in an Internet-based X.500 service. 


2.10.4. Use of X.500 for Non-White Pages Information 


The PSI White Pages Pilot Project has caused increasing and popular 
use of X.500 as a white pages services within the Internet community. 
However, the X.500 standard provides for much more than just this 
Service. Application processes, devices and security objects are 
just a few of the objects to be considered for future incorporation 
in the global X.500 database. 


2.10.5. Introduction of New X.500 Implementations 


Thought will have to be given to the use of commercial X.500 products 
in the future as QUIPU (the implementation recommended in this paper) 
may not meet all of the needs of the ESnet community. As commercial 
products mature and become stable, they will have to be incorporated 
into the ESnet X.500 service in a way which ensures interoperability 
and reliability. 


2.10.6. Interaction of X.500 and DECdns 


There is every indication that DECdns and X.500 will interoperate in 
some fashion in the future. Since there is an evolving DECdns 
namespace (i.e. OMNI) and an evolving X.500 DIT (i.e. NADF), some 
consideration should be given to how these two name trees will 
interact. All of this will be driven by the Digital Equipment 
Corporation's decisions on how to expand and incorporate its DECdns 
product with X.500. 
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3. X.400 - OSI Message Handling Services 
3.1. Brief Tutorial 


In 1984 CCITT defined a set of protocols for the exchange of 
electronic messages called Message Handling Systems (MHS) and is 
described in their X.400 series of recommendations. ISO incorporated 
these recommendations in their standards (ISO 10021). The name used 
by ISO for their system was MOTIS (Message-Oriented Text Interchange 
Systems). In 1988 CCITT worked to align their X.400 recommendations 
with ISO 10021. Currently when people discuss messaging systems they 
use the term X.400. These two systems are designed for the general 
purpose of exchanging electronic messages in a store and forward 
environment. The principle use being made of this system today is to 
support electronic mail. This section will give an overview of X.400 
as used for electronic mail. In the following sections, the term 
X.400 will be used to describe both the X.400 and MOTIS systems. 


The basic model used by X.400 MHS is that of a Message Transfer 
System (MTS) accessed via a User Agent (UA). A UA is an application 
that interacts with the Message Transfer System to submit messages on 
behalf of a user. A user is referred to as either an Originator 
(when sending a message) or a Recipient (when receiving one). The 
process starts out when an Originator prepares a message with the 
assistance of their UA. The UA then submits the message to the MTS 
for delivery. The MTS then delivers the message to one or more 
Recipient UAs. 


The MTS provides the general store-and-forward message transfer 
service. It is made up of a number of distributed Message Transfer 
Agents (MTA). Operating together, the MTAs relay the messages and 
deliver them to the intended recipient UAs, which then makes the 
messages available to the recipient (user). 


The basic structure of an X.400 message is an envelope and content 
(i.e. message). The envelope carries information to be used when 
transferring the message through the MTS. The content is the piece 
of information that the originating UA wishes delivered to the 
recipient UA. There are a number of content types that can be 
carried in X.400 envelopes. The standard user message content type 
defined by X.400 is called the Interpersonal (IP) message. An IP 
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message consists of two parts, the heading and body. The heading 
contains the message control information. The body contains the user 
message. The body may consist of a number of different body parts. 
For example one IP message could carry voice, text, Telex and 
facsimile body parts. 


The Management domain (MD) concept within the X.400 recommendations 
defines the ownership, operational and control boundary of an X.400 
administration. The collection consisting of at least one MTA and 
zero or more UAs owned by an organization or public provider 
constitutes a management domain (MD). If the MD is managed by a 
public provider it is called an Administration Management Domain 
(ADMD). The MD managed by a company or organization is called a 
Private Management Domain (PRMD). A Private MD is considered to 
exist entirely within one country. Within that country a PRMD may 
have access to one or more ADMDs. 


Each MD must ensure that every user (i.e UA) in the MD has at least 
one name. This name is called the Originator/Recipient (O/R) Name. 
O/R Names are constructed from a set of standard attributes: 

o Country Name 

o Administration Management Domain 

o Private Management Domain 

o Organization Name 

o Organizational Unit Name 

o Surname 

o Given name 

o Initials 

o Generational Qualifier 

An O/R name must locate one unambiguous O/R UA if the message is to 
be routed correctly through the Message Transfer Service. Currently 
each MD along the route a message takes determines the next MD's MTA 
to which the message should be transferred. No attempt is made to 
establish the full route for a message, either in the originating MD 
or in any other MD that acquires the store and forward responsibility 


for the message. 


Messages are relayed by each MD on the basis of the Management domain 
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portion of their O/R Name until arrival at the recipient MD. At 
which point, the other attributes in the name are used to further 
route to the recipient UA. Internal routing within a MD is the 
responsibility of each MD. 


.2.  ESnet X.400 Logical Backbone 


Currently within the ESnet community message handling services are 
implemented with a number of different mail products, resulting in 
what is classically known as an "n-squared" problem. For example, 
let's say that LLNL only uses QuickMail on site, PPPL only uses 
MAIL-11 (VMS MAIL), and CEBAF only uses SMTP mail. For LLNL to send 
mail to PPPL and CEBAF, is must support MAIL-11 and SMTP locally on- 
site. Likewise for PPPL to send mail to LLNL and CEBAF, it must 
support MAIL-11 and QuickMail locally.  Identically, this scenario 
exists for CEBAF. 


To alleviate this problem, a logical X.400 backbone must be 
established through out the entire ESnet backbone. Then, each ESnet 
backbone site will be responsible for only providing connectivity 
between it's local mail domains (QuickMail, MAIL-11, SMTP Mail, or 
even native X.400) and the logical X.400 backbone. One of the long- 
term goals is to establish X.400 as the "common denominator" between 
directly connected ESnet backbone sites. 


3. Naming Structure 


The name-spaces for X.500 and X.400 are completely different and are 
structured to meet different needs. The X.500 name-space is 
typically organized to allow quick, optimized searching; while the 
X.400 ORname is used to forward an X.400 message through several 
"levels" of MTAs (X.400 Message Transfer Agents). 


ESnet backbone sites will participate in the X.400 environment 
through one of two options; either participating in the ESnet Private 
Management Domain (PRMD) or operating a site PRMD. For most sites, 
utilizing the ESnet PRMD will be the simpler and preferable choice. 


3.1. Participating in the ESnet Private Management Domain 


ESnet backbone sites participating in the ESnet PRMD will have an 
X.400 name syntax as follows: 


/.../O=<site>/PRMD=ESnet/ADMD= /C=US/ 


A few examples of a possible X.400 ORnames using the above syntax 
are: 
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/PN-Smith/OU-Computations/O-LLNL/PRMD-ESnet/ADMD- /C-US/ 
/PN-Jones/OU-Physics/O-PPPL/PRMD-ESnet/ADMD- /C-US/ 


These sites will operate an MTA at the /O-«organization» level in the 
name hierarchy. 


3.3.2. Operating a Site Private Management Domain 


ESnet backbone sites which operate a PRMD will have an X.400 name 
syntax as follows: 


/.../O-«org»/PRMD-«site»/ADMD- /C=US/ 


A few examples of a possible X.400 ORnames using the above syntax 
are: 


/PN-Smith/O-Computations/PRMD-LLNL/ADMD- /C-US/ 
/PN-Jones/O-Physics/PRMD-PPPL/ADMD- /C-US/ 


These sites will operate an MTA at the /PRMD-«PRMD» level in the name 
hierarchy. This MTA will peer with the ESnet PRMD MTA. 


3.3.3. Detailed Name Structure 


GOSIP places several limits on allowable ORnames. After the 
/O-«organization» name, up to four levels of 
/OU-«organizational unit» names are allowed. The ORname string is 
then completed with the /PN-«personal name» field. 


All ORname fields must use characters from the ISO printable 
character set. Additionally, the following name length restrictions 


apply: 


PRMD Names 16 characters 
Organization Names 64 characters 
Organizational Unit Names 32 characters 
Personal Names 64 characters 


NOTE: A 40 character limit for Personal Names is now being 
studied by the CCIIT. 


Within these name constraints, the architecting of an organization's 
name space is a local matter. Sites are encouraged to consider ease 
of use and stability when determining their naming structure. 


3.4. X.400 Routing 


In the IP environment a SMTP MTA could use the Domain Name Service 
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(DNS) to locate connection information for the host closest to the 
recipient. With X.400, MTAs must know the remote MTAs name and 
password along with connection information. This is because of 
access control requirements on some X.400 systems. In X.400 MHS this 
information will, at some future date, be provided by X.500. In the 
mean time the routing and connection process within the X.400 
community is table driven. This solution requires a coordination and 
distribution effort to ensure a quick and reliable update of these 
tables. 


The current thinking on the problem of X.400 routing is to decompose 
the X.400 address space into a hierarchy, with each node in this 
hierarchy representing the entry point for an X.400 domain. These 
nodes have been commonly called Well Known Entry Points (WEPs). Each 
of these WEPs represent one X.400 MHS domain. For example: 


/O-LBL/PRMD-ESnet/ADMD- /C-US/ 
/O=NERSC/PRMD=ESnet/ADMD= /C=US/ 
/PRMD=ESnet/ADMD= /C=US/ 
/PRMD=ANL/ADMD= /C=US/ 
/PRMD=PNL/ADMD= /C=US/ 


To minimize the number of hops between Originators and Recipients it 
is the current recommendation of the X.400 community that every PRMD 
peer with all other PRMDs. 


The ESnet backbone will provide connectivity between multiple PRMDs 
(the ESnet PRMD and any site operated PRMDs), each with associated 
well-know entry point MTAs. Each of these PRMD-level MTAs must be 
configured with routing and mapping information about each other to 
enable peer-to-peer PRMD routing. These routing tables should be 
updated immediately upon the discovery of new/changed X.400 
connectivity information. These tables will be made available to the 
ESnet community via the ESnet Information Server. Once placed on- 
line, a notification message announcing the availability of this new 
routing information will be sent to every WEP owner via the E-mail 
mechanism described in Section 3.5.1. It is recommended that WEP 
administrators should retrieve this new routing information and 
update their MTAs within 10 working days. 


The well-known entry point MTA for each PRMD can route down to an 
Organizational level MTA or laterally to the well-known entry point 
of a peer PRMD MTA. 


For example, the ESnet MTA would route a message with the address: 


/PN-Funk/OU-2CS/O-PPPL/PRMD-ESnet/ADMD- /C=US/ 
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to a well-known entry point for PPPL (O-PPPL). PPPL must own and 
operate their own X.400 MTA, and it must be configured to accept 
X.400 messages from the ESnet MTA. Thus, the interpretation of 
remaining "/PN-Funk/OU-CS" is left to the PPPL MTA to route. 


Mail sent from PPPL's MTA would be routed to the ESnet's MTA (PRMD) 
to be eventually routed to its destination. 


The ESnet MTA will also route to peer MTAs which are well-known entry 
points for other PRMDs (e.g. ESnet backbone site PRMDs, XNREN, Hughes 
Air Craft, NASA, CDC). For example, the ESnet MTA would route a 
message with the address: 


/PN-Smith/OU-MS/O-RL/PRMD-PNL/ADMD- /C=US/ 


to a well-known entry point for PNL (PRMD-PNL). PNL must own and 
operate their own X.400 MTA, and it must be configured to accept 
X.400 messages from the ESnet MTA (as well as possibly other PRMDs). 
Thus, the interpretation of the remaining "/PN-SMITH/OU-MS/O-RL" is 
left to the PNL MTA to route. 


Mail sent from PNL's MTA (PRMD) would be routed to the well-known 
entry point for the PRMD indicated in the destination address. 


Additionally, a site operated PRMD must be able to route mail to any 
other peer-PRMD within the ESnet community. 


3.4.1. Responsibilities in Operating an X.400 PRMD MTA 


If the X.400 world were to operate exactly as the standard 
recommends, PRMDs would only peer with other PRMDs when connectivity 
is available and traffic demand is sufficient, and would utilize ADMD 
services to reach all other PRMDs. In reality, many PRMDs will not 
subscribe to an ADMD service and will only be reachable through PRMD 
peering. 


Most communities, such as the ESnet, desire the fullest PRMD 
interconnectivity possible to minimize the need for ADMD services. 
Community PRMD operational requirements stem from a policy of 
achieving large scale peering among PRMD operators within the 
community. 


Work is continuing in the IETF X.400 Operations Working Group to 
produce an RFC that specifies the operational requirements that must 
be implemented by X.400 Management Domains. "Requirements for X.400 
Management Domains (MDs) Operating in the Global Research and 
Development X.400 Service", this document is listed in Appendix G. 
ESnet will comply with all the requirements outlined in this 
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document. It is the recommendation that all ESnet PRMDs follow the 
requirements specified in this document. 


As an overview, this document specifies that each PRMD will provide 
at least one WEP and that all PRMDs must be interconnected. There 
are a number of PRMDs in the International X.400 service that have 


different communication stack requirements. For example: 
Stack 1 Stack 2 Stack 3 Stack 4 
Transport Layer 4 TPO TP4 RFC-1006 TPO 
Network Service 1-3 X.25 CLNS TCP/IP CONS 


To meet the requirement that all PRMDs must be interconnected a PRMD 
must support one or more of the above stacks. For stacks that are 
not supported the PRMD must negotiate with another PRMD or ADMD to 
relay messages to a Management Domain that does support the other 
stacks. 


The PRMD requirements also suggest that PRMDs support downgrading of 
X.400 1988 to X.400 1984. Also, the PRMD must be reachable from the 
Internet Mail service. This means the PRMD must maintain an Internet 
Mail/X.400 gateway. 


In all cases, members of the ESnet community who operate a PRMD 
should notify ESnet of the WEP and MTA information required to 
perform peering. 


3.4.2. Responsibilities in Operating an X.400 Organizational MTA 


ESnet will provide PRMD service to the ESnet community.  ESnet will 
peer with the other PRMDs in the International X.400 service and 
provide a WEP for the ESnet community. An Organization/site needs to 
decide if they are going to comply with the above PRMD requirements 
or act as an organization associated to the ESnet PRMD. Minimally, 
an organizational MTA will only have to support one of the protocol 
stacks provided by it associated PRMD. But in all cases, the site 
will need to provide a WEP and register/list their MTA(s) with ESnet. 


3.5. Services Provided by ESnet 
ESnet will provide PRMD service to those members of the ESnet 
community who desire it. ESnet will peer with other PRMDs in the 
International community (e.g. XNREN, Hughes Air Craft, NASA, CDC) and 
provide a WEP for the ESnet community; the intent is to provide the 


fullest PRMD level X.400 services. 


ESnet will deploy two, PRMD level, X.400 MTAs in geographically 
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disperse locations. These MTAs will be able to forward mail for 
directly connected ESnet backbone sites, as well as to and from the 
peered PRMDs. 


3.5.1. X.400 Operations Mailing List 
ESnet will provide an X.400 operations mailer for announcements and 
to allow the sharing of X.400 operational information in the ESnet 


community. 


General discussion: x400-ops@es.net 
To subscribe: x400-ops-requestües.net 


3.5.2. MTA Routing Table on ESnet Information Server 


ESnet will maintain forwarding information about ESnet community MTAs 
at the /PRMD=<PRMD> or /O=<organization> levels (depending on what 
level the site MTA is operating). This information will be available 
for use in configuring directly connected ESnet site operated MTAs. 
This information will be made available in a machine independent 
format on the ESnet Information Server. 


3.5.3. MTA Routing Table Format 


The ESnet staff will determine the details of information format, 
update frequency, obtaining, and disseminating the information based 
on operational experience and constraints. 


3.5.4. Gateway Services and Multiprotocol Stack Support 


The ESnet MTAs will minimally support bidirectional SMTP-X.400 mail 
gateway capabilities, and will operate over the OSI CLNS protocol (as 
defined by GOSIP) and RFC-1006 stacks. Configuration and operation 
of mail protocol gateway functions will be governed by the ESnet 
staff. 


Backbone site MTAs which service ORnames at the /O-«site» level under 
the ESnet PRMD must utilize one of the ESnet PRMD supported protocol 
stacks. This requirement assures that all users of the ESnet PRMD 
will be able to communicate to one another via the ESnet PRMD MTA. 


Backbone site MTAs which service ORnames in PRMDs other than 
/PRMD-ESnet must utilize the OSI CLNS stack for GOSIP conformance. 
Use of the RFC-1006 stack is optional. This requirement assures that 
all PRMDs in the ESnet community will be able to peer with the ESnet 
PRMD. 
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3.5.5.  Registering/Listing your PRMD or Organizational MTA with ESnet 


To provide for the connection and routing requirements in X.400 you 
will need to register/list your MTA with ESnet. This information 
will be maintained in tables on the ESnet Information Server.  ESnet 
will also maintain information on the International X.400 service. 
ESnet will use the same format for information as maintained by the 
International X.400 service. This is described in detail in a IETF 
X.400 operations paper "Routing Coordination for X.400 MHS Services 
within a Multiprotocol/Multinetwork Environment". This paper is a 
working draft, see Appendix G. It describes a machine independent 
form for distribution of X.400 information. 


There are three tables that must be maintained and exchanged by the 
top level WEPS. 


1. The Community Document 
2. The WEP Document 
3. The Domain Document 


ESnet will submit these documents to the International X.400 
community on behalf of the ESnet Community. If an ESnet PRMD wishes 
to peer with the International PRMDs they will need to submit these 
documents to that community. 


The Community document is used to list the central coordination point 
and file server where all MHS documents will be stored. It also 
lists the communication stacks used by the MHS community. This 
document will be submitted to the International X.400 service by 
ESnet for the ESnet Community.  ESnet PRMDs and Organizations do not 
need to submit this form to ESnet. If an ESnet PRMD wishes to peer 
with the International X.400 service then they must submit this form 
to that community. 


Each ESnet MHS domain will need to submit a WEP and Domain Document 
to ESnet. The WEP document is used to list the WEPs used by an ESnet 
MHS domain. It will contain all the information that is needed for 
MTA connection and access control.  ESnet will submit the ESnet 
community WEP and Domain Documents to the International X.400 
service. The WEP document consists of a list of WEPs, with the 
following information for each one: 


o The MTA Name 


o Password 


ESCC X.500/X.400 Task Force [Page 31] 


RFC 1330 X.500 and X.400 Plans for ESnet May 1992 


o Which MTS supported 
o Which standard, 84 and/or 88 
o Connection information outbound 
o Connection information inbound 
o Computer system information 
o Point of contact 
The Domain Document specifies all the X.400 domains managed by a 
Site. It indicates the person responsible and which WEP services 
which Domain. This document contains the following information 
repeated for each Domain: 
o X.400 Domain 
o Point of Contact 
o Relaying WEP(s) 

3.6. X.400 Message Routing Between ADMDS and PRMDS 
While ESnet will provide X.400 routing service for systems, it cannot 
provide routing via commercial X.400 carriers at this time. The 
FTS-2000 charge for routing X.400 messages is $.45 (US) plus X.25 
packet charges. This could result in a charge of several dollars for 
large messages, a real possibility with the multi-media capacity of 
X.400. The payment of this fee is not within the charter of ESnet 


and the provision of a charging mechanism to charge member sites is 
not currently contemplated. 


3.7. X.400 Registration Requirements 


It is recommended by the CCITT that all X.400 PRMD names be 
nationally unique. This is a current CCITT agreement and allows 
direct PRMD-PRMD peer routing. Since national uniqueness is 
required, registration should be performed through an appropriate 
registration authority (such as ANSI). 


X.400 organization names must be unique within a PRMD. There is no 
need for national uniqueness. Registration of an X.400 organization 


name should be conducted through the PRMD operator. 


The registration of X.400 names below the organization level are 
usually a local matter.  Uniqueness within the context of a superior 
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name should always be maintained. 


See Section 4 for a more complete description of OSI registration 
issues and procedures. 


.8. Future X.400 Issues to be Considered 


.9.1. X.400 Mail Routing to International DOE Researchers 


Currently there are DOE researchers located in Switzerland, Japan, 
Germany, China and Brazil.  PRMD level connectivity to these 
international locations does not exist presently. Since ESnet is not 
chartered to pay for commercial X.400 services on behalf of the ESnet 
community, "buying" this service is not a viable option. 


There are efforts taking place to provide international X.400 service 
over the (international) Internet. Once this becomes fully 
operational, further research will have to be performed to see if 
this provides the X.400 connectivity needed to support the DOE 
researchers located abroad. 


8.2. X.400 (1984) and X.400 (1988) 


The ESnet MTAs will initially support the 1984 version of the X.400 
standard. As the use of 1988 X.400 becomes more prevalent, support 
for the newer standard will need to be addressed. One important 
point, once the ESnet MTAs become 1988 X.400 compliant, they will 
also have so support "downgrading" to 1984 X.400 to ensure reliable 
X.400 mail delivery to the ESnet community. 


8.3. X.400 Interaction with X.500 
This is discussed in Section 2.10.2. 
OSI Name Registration and Issues 


Implementing OSI services requires that certain information objects 
(e.g., people, information processing systems and applications) must 
be unambiguously identifiable on a global basis. These objects may 
be defined by a variety of organizations, e.g., ISO/IEC, CCITT, 
commercial, and government. 


To meet this requirement ISO/IEC and CCITT have established a 
hierarchical structure of names (a tree). The top level of the 
naming tree, shared by ISO and CCITT, represents the global naming- 
domain. Naming domains are managed by registration authorities. A 
registration authority can delegate authority for part of its 
naming-domain to another (lower level) registration authority, thus 
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forming the tree. 
Each object can be given a unique and unambiguous name by registering 
the object's name with an OSI registration authority at an 


appropriate level in the naming tree. 


OSI name registration authorities and their procedures are expected 


to change over time. Since names are intended to be stable, these 
changes (hopefully!) will have minimal impact on existing OSI name 
registrations. 


This section describes the role of OSI registration authorities, the 
difference between a "registration" and a "notification", and sources 
of nationally unique names. Information about three OSI name 
registration authorities; the American National Standards Institute 
(ANSI), the General Services Administration (GSA), and the U.S. 
Department of Energy (U.S. DOE); are given. 


Registration of a name often requires stating a "right" to that name. 
However, an OSI name registration does not guarantee legal name 
rights. Name rights should be reviewed by legal experts prior to 
registration. Information about the U.S. Department of Commerce, 
Patent and Trademark Office (PTO) (potentially useful in asserting or 
defending name rights) is given below. 


4.1. Registration Authorities 


OSI names are obtained through OSI name registration authorities by a 
registration process. The selection of which particular registration 
authority to use is determined by the desired level of the OSI name 
in the naming hierarchy, possible restrictions on the names allocated 
by each registration authority, and the applicability rules (will 
they service your request) of each registration authority. 


An OSI name registration authority allocates OSI names from the 
particular naming-domain it controls. Every registration authority 
can trace its naming authority to its parent registration authority, 
and ultimately to the top (global) level of the naming hierarchy. 


4.2. Registration Versus Notification 
Registering an OSI name guarantees its uniqueness and lack of 
ambiguity. For a name to be useful however, other parties (besides 
the registration authority) will need to be notified of the name and 


its usage. 


There is a clear distinction between registration (obtaining an OSI 
name) and notification (informing others of a name and its use). 
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Often the term "registration" is used to describe both activities, 
this is a potential source of confusion. 


For example, NADF and PSI (see Section 2) are not OSI registration 
authorities.  NADF may operate state registration authorities in the 
future, if delegated that administrative right by the states. PSI 
operates an X.500 pilot project and needs to be notified of 
registered names when organizations join their pilot. 


X.400 ADMD operators are also not OSI registration authorities, 
although they accept notification of X.400 PRMD names used by their 
customers. 


The PTO is not an OSI registration authority.  PTO names have no 
meaning in an OSI context. 


4.3. Sources of Nationally Unique Name Registration 


There are four potential sources of nationally unique names which are 
of interest to the ESnet community. These are ANSI, GSA, U.S. DOE 
and the states. An overview of the ANSI, GSA, and U.S. DOE 
procedures are given in later sections. 


In order to maintain national uniqueness "constructed name syntax" is 
used by GSA, U.S. DOE, and the states. The form of each name is 
shown below, "name" is the name presented to the registration 
authority for registration. 


1. ANSI names are of the form "name". 
2. GSA names are of the form "GOV+name". 
3. U.S. DOE names are of the form "GOV+USDOE+name". 
4. State names are of the form "CAtname" (using California). 
State name registration authorities are not in operation at this 
time. The use of U.S. DOE as a nationally unique name registration 
Source is not recommended due to the awkwardness of a double 
constructed name. 

4.4. How to Apply for ANSI Organization Names 
ANSI is the root U.S. source of OSI recognized nationally unique 
organization names.  ANSI registration costs $2500 and results in 
both an alphanumeric name and an associated numeric name. These 


names may be used for a variety of purposes in X.400, X.500, and 
other OSI services. 
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For ANSI OSI organization name registration forms and instructions, 
you should send your request to: 


American National Standards Institute, Inc. 
Attn: Beth Somerville 

OSI Registration Coordinator 

11 West 42nd Street 

New York, NY 10036 

Phone: (212) 642-4976 


ANSI registration procedures include a 90 day public review period 
during which name requests can be easily challenged. 


There is a mechanism to forward ANSI requests to the GSA, it is 
discussed in the GSA section below. 


4.5. How to Apply for GSA Organization Names 


GSA is the registration authority for government use of GOSIP, their 

registration services are free for federal government organizations. 

Names assigned by GSA always begin with the characters "GOV+" and are 
limited to 16 characters. By agreement with ANSI, these GSA assigned 
names are national unique. 


For GSA OSI Organization Name registration forms and instructions, 
you should send your request to: 


General Services Administration 

Office of Telecommunications Services 
Registration Services, Room 1221-L KBA 
18th and F Streets, N.W. 

Washington, D.C. 20405 


4.5.1. GSA Designated Agency Representatives 
When preparing the GSA registration form a designated agency 
representative must sign where it says "Registration Official Name 


and Signature". GSA will refuse requests missing this signature. 


The GSA designated Agency Representative for the Department of Energy 
is: 
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Steve Hackman 

Electronics Engineer 

U.S. Department of Energy 
AD-241.3/GTN 

Washington, D.C. 20585 


Office Phone: (301) 903-6111 
Office FAX: (301) 903-4125 
E-Mail: hackman@gosip.xosi.doe.gov 


4.5.2. Forwarding of ANSI Registrations to GSA 


ANSI registration requests can be forwarded automatically to the GSA. 
This is the equivalent of registering with both ANSI and GSA. The 
result is two nationally unique OSI name registrations, "name" from 
ANSI and "GOV+name" from GSA. 


There is no GOSIP requirement for GSA registration but many feel the 
additional GSA registration may be useful. 


Assuming your organization is a federal government organization, 
answer the last three questions on the ANSI registration form as 
shown below: 


1. Do you wish the information supplied in the request to remain 
confidential? NO. 


2. Do you wish to have your organization name registered with the 
U.S. GOSIP Registration Authority (a.k.a. GSA)? YES. 


3. Is your organization an organization of the Federal Government? 
YES. 


You must indicate on the application form the approval of the GSA 
designated agency representative (Steve Hackman). He does not sign 
as "Signature of Requestor", but some notation of his approval must 
be attached or GSA will reject the forwarded application. 


4.6. How to Apply for U.S. DOE Organization Names 


ESnet sites are encouraged to review the DOE GOSIP procedures and 
guidelines in planning their GOSIP activities. This document does 
not conflict with current DOE GOSIP policies. 


DOE can assign nationally unique names which are prefixed by the 
string "GOV+USDOE+". Use of this name source is not recommended; 
there is no apparent advantage in using U.S. DOE over GSA as a source 
of nationally unique names. 
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Copies of current U.S. DOE GOSIP policies, guidelines, and 
registration forms may be obtained through site DOE naming 
authorities or Steve Hackman. 


4.7. Why Apply for a Trademark with the PTO? 


Legal issues may arise concerning the rights to use a desired name. 
OSI name registrations are not intended to "legally protect" name 
usage rights; that is not their function. 


Consultation with legal experts concerning the rights to use a name 
being registered is strongly advised, this recommendation does not 
offer specific legal guidance. Applying for a trademark may be 
considered as a means to assert or protect the rights to a name. 


Per the PTO trademark application instructions there may be several 
benefits in obtaining a trademark. 


o The filing date of the application is a constructive date of 
first use of the mark in commerce (this gives registrant 
nationwide priority as of the date). 

o The right to sue in Federal court for trademark infringement. 


o Constructive notice of claim of ownership. 


o Limited grounds for attacking a registration once it is five 
years old. 


4.8. How to Apply for a Trademark with the PTO 


You should obtain a trademark application and detailed instructions 
from the U.S. Department of Commerce, Patent and Trademark Office. 
This can be done by mailing your request to the address below, or 
calling the PTO at the phone number below: 


U.S. Department of Commerce 
Patent and Trademark Office 
Washington, D.C. 20231 
Phone: (703) 557-INFO 


NOTE: The following information is based on ESnet experience in 
filing for a trademark based on prior use. 


After you receive your application, you will need to perform the 
following steps. 


1. Complete the written application form. If you have more than 
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one name you are filing, you must complete a separate form for 
each name. 


2. Provide a black-and-white drawing of the mark. In the case 
where there is no artwork, only text, the text must be 
centered on the page in uppercase. 


3. Provide a check in the amount of $175 (for each application) 
made payable to the Commissioner of Patents and Trademarks. 


4. Provide three specimens showing actual use of the mark on or 
in connection with the goods or services. 


The class of goods/services associated with this trademark must be 
Specified on the registration form. The currently defined classes of 
services are: 


35 Advertising and business. 

36 Insurance and financial. 

37 Construction and repair. 

38 Communication. 

39 Transportation and storage. 
40 Material treatment. 

41 Education and entertainment. 
42 Miscellaneous. 


So, for example, there could be two (or more) "ESnet" trademarks, 
with each trademark associated with a different service class. Thus, 
trademarks are not nationally unique. 


Before submitting your form, you should see if your trademark is 
already registered to someone else (for the service class you 
Specified). This is typically done by your legal department through 
the PTO Trademark Search Library. 


Since the PTO form is a legal document, you must involve your legal 
department and the documents may only be signed by someone who is a 
legally recognized representative of your organization. For example, 
in applying for the service mark "ESnet", the "Applicant Name" was 
"The Regents of the University of California", and the legally 
recognized representative was Dr. John Nuckolls, the director of the 
Lawrence Livermore National Laboratory. 


4.9. Future Name Registration Issues to be Considered 
4.9.1. ANSI Registered ADMD and PRMD Names 


There are discussions in the ANSI and CCITT communities revolving 
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around the idea of having a formal registration of all ADMD and PRMD 


Names (not just ANSI Organization Names). The ideas being exchanged 
include having a separate ANSI national registry for these names, and 
having to pay a periodic "license" fee. This is just in the idea 


discussion phase now, but it may impact the cost of ANSI ADMD and 
PRMD Name registration in the near future. 


Glossary 

AA — See ADMINISTRATIVE AUTHORITY. 

ADDMD - See ADMINISTRATIVE DIRECTORY MANAGEMENT DOMAIN. 

ADMD - See ADMINISTRATION MANAGEMENT DOMAIN. 

ADMINISTRATION - An Administration denotes a public telecommunications 
administration or other organization offering public 
telecommunications services. 

ADMINISTRATION MANAGEMENT DOMAIN - An Administrative Management Domain 
(ADMD) is a management domain managed by an Administration; 
generally one of the common carriers (e.g. AT&T, MCI, U.S. Sprint, 
etc.). 

ADMINISTRATIVE AUTHORITY - An entity which has administrative control 
over all entries stored within a single Directory System Agent 
(DSA). 

ADMINISTRATIVE DIRECTORY MANAGEMENT DOMAIN - An Administrative Directory 
Management Domain (ADDMD) is a Directory Management Domain (DMD) 
which is managed by an administration. 


AE —- See APPLICATION ENTITY. 


ALIAS - An entry of the class "alias" containing information used to 
provide an alternative name for an object. 


ANSI - The American National Standards Institute.  ANSI is the official 
representative of the United States to ISO. 


AP —- See APPLICATION PROCESS. 


APPLICATION ENTITY - An application entity is the OSI portion of an 
Application Process (AP). 


APPLICATION LAYER - The application layer is the portion of an OSI 


System ultimately responsible for managing communication between 
application processes (APs). 
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APPLICATION PROCESS - An application process is an object executing in a 
real system (computer). 


APPLICATION SERVICE ELEMENT - An application service element (ASE) is 


the building block of an application entity (AE). Each AE consists 
of one or more service elements, as defined by its application 
context. 


ASE - See APPLICATION SERVICE ELEMENT. 


ATTRIBUTE - An attribute is the information of a particular type 
concerning an object and appearing in an entry describing that 
object in the Directory Information base (DIB). 


ATTRIBUTE TYPE - An attribute type is that component of an attribute 
which indicates the class of information given by that attribute. 


ATTRIBUTE VALUE - An attribute value is a particular instance of the 
class of information indicated by an attribute type. 


BASE ATTRIBUTE SET - A minimum set of attributes whose values 
unambiguously identify a particular management domain. 


BODY - The body of the IP-message is the information the user wishes to 
communicate. 


CCITT - An international standards making organization specializing in 
international communications standards and chartered by the United 
Nations.  "CCITT" is a french acronym meaning the International 
Telephone and Telegraph Consultative Committee. 


CHAINING - Chaining is a mode of interaction optionally used by a 
Directory System Agent (DSA) which cannot perform an operation 
itself. The DSA chains by invoking the operation of another DSA 
and then relaying the outcome to the original requestor. 


CLNP - The OSI Connectionless Network Protocol.  CLNP's use is required 
by GOSIP. 


CONTENT - The piece of information that the originating User Agent (UA) 
wishes delivered to the recipient UA. For inter-personal messaging 
(IPM) UAs, the content consists of either an IP message or an IPM- 
status-report. 


COOPERATING USER AGENT - A User Agent (UA) that cooperates with another 


recipient's UA in order to facilitate the communication between 
originator and recipient. 
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DAP —- See DIRECTORY ACCESS PROTOCOL. 


DELIVERY - The interaction by which the Message Transfer Agent (MTA) 
transfers to a recipient User Agent (UA) the content of a message 
plus the delivery envelope. 


DELIVERY ENVELOPE - The envelope which contains the information related 
to the delivery of the message. 


DESCRIPTIVE NAME - A name that denotes one and only one user in the 
Message Handling System (MHS). 


DIB - See DIRECTORY INFORMATION BASE. 


DIRECTORY - The Directory is a repository of information about objects 
and which provides directory services to its users which allow 
access to the information. 


DIRECTORY ACCESS PROTOCOL - The Directory Access Protocol (DAP) is the 
protocol used between a Directory user Agent (DUA) and a Directory 
System Agent (DSA). 


DIRECTORY ENTRY - A Directory Entry is a part of the Directory 
Information Base (DIB) which contains information about an object. 


DIRECTORY INFORMATION BASE - The Directory Information Base (DIB) is the 
complete set of information to which the Directory provides access 
and which includes all pieces of information which can be read or 
manipulated using the operations of the Directory. 


DIRECTORY INFORMATION TREE - The Directory Information Tree (DIT) is the 
Directory Information Base (DIB), considered as a tree, whose 
vertices (other than the root) are the Directory entries. 


DIRECTORY MANAGEMENT DOMAIN - A Directory Management Domain (DMD) is a 
collection of one or more Directory System Agents (DSAs) and zero 
or more Directory User Agents (DUAs) which is managed by a single 
organization. 


DIRECTORY SYSTEM AGENT - A Directory System Agent (DSA) is an OSI 
application process which is part of the Directory. 


DIRECTORY SYSTEM PROTOCOL - The Directory System Protocol (DSP) is the 
protocol used between two Directory System Agents (DSAs). 


DIRECTORY USER - A Directory user is the entity or person that accesses 
the Directory. 
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DIRECTORY USER AGENT - A Directory User Agent (DUA) is an OSI 
application process which represents the user in accessing the 
Directory. 


DISTINGUISHED NAME - The distinguished name of a given object is the 
sequence of relative distinguished names (RDNs) of an entry which 
represents the object and those of all of its superior entries (in 
descending order). 

DIT - See DIRECTORY INFORMATION TREE. 

DMD - See DIRECTORY MANAGEMENT DOMAIN. 

DN —- See DISTINGUISHED NAME. 


DNS - See DOMAIN NAME SERVICE. 


DOMAIN NAME SERVICE - A hierarchical, distributed naming service 
currently used in the Internet. DNS names typically take the form 
of «machine.site.domain», where «.domain» may be ".COM", ".EDU", 
".GOV", ".MIL", ".NET", ".ORG" or ".<country-code>". 


DSA - See DIRECTORY SYSTEM AGENT. 

DSP - See DIRECTORY SYSTEM PROTOCOL. 

DUA - See DIRECTORY USER AGENT. 

ENCODED INFORMATION TYPE - It is the code and format of information that 
appears in the body of an IP-message (examples of coded information 


types are Telex, TIFO (Group 4 Facsimile), and voice). 


ENVELOPE - A place in which the information to be used in the 
submission, delivery and relaying of a message is contained. 


FIPS - Federal Information Processing Standard.  FIPS are produced by 
NIST and specify a standard for the federal government, most FIPS 
reference other formal standards from ANSI, IEEE, ISO or CCITT. 


GOSIP - The Government Open System Interconnection (OSI) Profile.  GOSIP 
is a FIPS which defines the elements of OSI to be required by 
government purchasers and how those elements should be implemented. 
GOSIP is based on OSI standards and OIW implementor's agreements. 


HEADING - The heading of an IP-message is the control information that 
characterizes an IP-message. 


INTERPERSONAL MESSAGING - Interpersonal Messaging (IPM) is communication 
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between persons by exchanging messages. 


INTERPERSONAL MESSAGING SERVICE - The set of service elements which 
enable users to exchange interpersonal messages. 


INTERPERSONAL MESSAGING SYSTEM - An Interpersonal Messaging System 
(IPMS) is the collection of User Agents (UAs) and Message Transfer 
Agents (MTAs), which provide the Interpersonal Messaging Service. 


IP - A non-OSI network protocol, the Internet Protocol, used extensively 
in the Internet.  CLNP is the OSI alternative to IP. 


IP-MESSAGE - An IP-message carries information generated by and 
transferred between Interpersonal Messaging (IPM) User Agents 
(UAs). An IP-message contains a Heading and a Body. 


IPM - See INTERPERSONAL MESSAGING. 
IPM-STATUS-REPORT - The pieces of information generated by an 
Interpersonal Messaging (IPM) User Agent Entity (UAE) and 


transferred to another IPM UAE, either to be used by that UAE or to 
be conveyed to the user. 


IPMS - See INTERPERSONAL MESSAGING SYSTEM. 


ISO - An international standards making organization which, among other 
things, develops OSI standards. 


MANAGEMENT DOMAIN - The set of Message Handling System (MHS) entities 
managed by an Administration or organization that includes at least 
one Message Transfer Agent (MTA). 


MD - See MANAGEMENT DOMAIN. 


MESSAGE - In the context of Message Handling Systems (MHSs), the unit of 
information transferred by the Message Transfer System (MTS). It 
consists of an envelope and a content. 


MESSAGE HANDLING ADDRESS - An Originator/Recipient (O/R) address which 
is comprised of an Administrative Management Domain (ADMD), a 
country name, and a set of user attributes. 


MESSAGE HANDLING SYSTEM - The set of User Agents (UAs) plus the Message 
Transfer System (MTS). 


MESSAGE TRANSFER AGENT - The functional component that, together with 
the other Message Transfer Agents (MTAs), constitutes the Message 
Transfer System (MTS). The MTAs provide message transfer service 
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elements by: (1) interacting with originating User Agents (UAs) 
via the submission dialogue, (2) relaying messages to other MTAs 
based upon recipient designations, and (3) interacting with 
recipient UAs via the delivery dialogue. 


MESSAGE TRANSFER AGENT ENTITY - The Message Transfer Agent Entity (MTAE) 
is an entity, located in an MTA, that is responsible for 
controlling the Message Transfer Layer (MTL). It controls the 
operation of the protocol to other peer entities in the MTL. 


MESSAGE TRANSFER LAYER - The Message Transfer Layer (MIL) is a layer in 
the Application layer that provides Message Transfer System (MTS) 
Service elements. These services are provided by means of the 
services of the layer below plus the functionality of the entities 
in the layer, namely the Message Transfer Agent Entities (MTAEs) 
and the Submission and Delivery Entities (SDEs). 


MESSAGE TRANSFER PROTOCOL - The Message Transfer Protocol (P1) is the 
protocol which defines the relaying of messages between Message 
Transfer Agents (MTAs) and other interactions necessary to provide 
Message Transfer layer (MTL) services. 

MESSAGE TRANSFER SERVICE - The Message Transfer Service is the set of 
optional service elements provided by the Message Transfer System 
(MTS). 

MESSAGE TRANSFER SYSTEM - The Message Transfer System (MTS) is the 
collection of Message Transfer Agents (MTAs), which provide the 
Message Transfer Service elements. 

MHS - See MESSAGE HANDLING SYSTEM. 

MTA - See MESSAGE TRANSFER AGENT. 

MTAE - See MESSAGE TRANSFER AGENT ENTITY. 

MTL - See MESSAGE TRANSFER LAYER. 


MTS - See MESSAGE TRANSFER SYSTEM. 


MULTICASTING - Multicasting is a mode of interaction which may 
optionally be used by a Directory System Agent (DSA) which cannot 
perform an operation itself. The DSA multicasts the operation 
(i.e. it invokes the operation of several other DSAs (in series or 
in parallel) and passes an appropriate outcome to the original 
requestor). 


NAME - A name is a construct that singles out a particular object from 
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all other objects. A name must be unambiguous (i.e. denote just 
one object); however, it need not be unique (i.e. be the only name 
which unambiguously denotes the object). 


NIST - The national institute of standards, a government organization 
which develops, endorses, and promulgates standards for use by the 
U.S. government. 


O/R ADDRESS - See ORIGINATOR/RECIPIENT ADDRESS. 


O/R NAME - See ORIGINATOR/RECIPIENT NAME. 


OBJECT (OF INTEREST) - Anything in some "world", generally the world of 
telecommunications and information processing or some part thereof, 
which is identifiable (i.e. can be named), and which it is of 
interest to hold information on in the Directory Information Base 
(DIB). 


OIW - The OSI Implementors workshop. OIW is one of three regional 
workshops (OIW, EWOS, AOW), which specifies implementation 
agreements for base OSI standards.  OIW's participants are mostly 
from the Americas and the OIW is jointly sponsored by the IEEE 
(Institute of Electrical and Electronic Engineers) and NIST. 


OPEN SYSTEMS INTERCONNECTION - A term referring to the capability of 
interconnecting different systems. 


ORIGINATING USER AGENT - The Originating User Agent (UA) is a UA that 
submits to the Message Transfer System (MTS) a message to be 


transferred. 


ORIGINATOR - A user, a human being or computer process, from whom the 
Message Handling System (MHS) accepts a message. 


ORIGINATOR/RECIPIENT ADDRESS - A descriptive name for a User Agent (UA) 
that contains certain characteristics which help the Message 
Transfer System (MTS) to locate the UA's point of attachment. An 
Originator/Recipient (O/R) address is a type of O/R name. 


ORIGINATOR/RECIPIENT NAME - The Originator/Recipient Name (O/R Name) is 
the descriptive name for a User Agent (UA). 


OSI - See OPEN SYSTEMS INTERCONNECTION. 
PRDMD - See PRIVATE DIRECTORY MANAGEMENT DOMAIN. 


PRIMITIVE NAME - A name assigned by a naming authority. Primitive names 
are components of descriptive names. 
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PRIVATE DIRECTORY MANAGEMENT DOMAIN - A Private Directory Management 
Domain (PRDMD) is a Directory Management Domain which is managed by 
an organization other than an administration. 


PRIVATE MANAGEMENT DOMAIN - A Private Management Domain (PRMD) is a 
management domain managed by a company or non-commercial 
organization. 

PRMD - See PRIVATE MANAGEMENT DOMAIN. 

RDN - See RELATIVE DISTINGUISHED NAME. 


RECIPIENT - A user, a human being or computer process, who receives a 
message from the Message Handling System (MHS). 


RECIPIENT USER AGENT - A User Agent (UA) to which a message is delivered 
or that is specified for delivery. 


REFERRAL - A referral is an outcome which can be returned by a Directory 
System Agent (DSA) which cannot perform an operation itself, and 
which identifies one or more other DSAs more able to perform the 
operation. 


RELATIVE DISTINGUISHED NAME - A Relative Distinguished Name (RDN) is a 
set of attribute value assertions, each of which is true, 
concerning the distinguished values of a particular entry. 


RELAYING - The interaction by which one Message Transfer Agent (MTA) 
transfers to another MTA the content of a message plus the relaying 
envelope. 


RELAYING ENVELOPE - The envelope which contains the information related 
to the operation of the Message Transfer System (MTS) plus the 
Service elements requested by the originating User Agent (UA). 


RFC - Request for Comments. The RFC’s are documents used to propose or 
Specify internet community standards. 


ROOT - The vertex that is not the final vertex of any arc is referred to 
as the root vertex (or informally as the root) of the tree. 


SCHEMA - The Directory Schema is the set of rules and constraints 
concerning the Directory Information Tree (DIT) structure, object 
class definitions, attribute types, and syntaxes which characterize 
the Directory Information base (DIB). 


SDE - See SUBMISSION AND DELIVERY ENTITY. 
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SMTP - Simple Mail Transfer Protocol. An e-mail protocol frequently 
used by the Internet community. 


SUBMISSION - The interaction by which an originating User Agent (UA) 
transfers to a Message Transfer Agent (MTA) the contents of a 
message plus the submission envelope. 


SUBMISSION AND DELIVERY ENTITY - The Submission and Delivery Entity 
(SDE) is an entity located in the Message Transfer Layer (MTL), 
co-resident with a User Agent (UA) and not with a Message Transfer 
Agent (MTA), and responsible for controlling the submission and 
delivery interactions with a Message Transfer Agent Entity (MTAE). 


SUBMISSION AND DELIVERY PROTOCOL - The Submission and Delivery Protocol 
(P3) is the protocol which governs communication between a 
Submission and Delivery Entity (SDE) and a Message Transfer Agent 
Entity (MTAE). 


SUBMISSION ENVELOPE - The envelope which contains the information the 
Message Transfer System (MTS) requires to provide the requested 
service elements. 


TCP - A non-OSI transport protocol, the Transmission Control Protocol, 
used extensively in the Internet. TP4 is the OSI alternative to 
TCP. 


TPO - An OSI transport protocol specified by GOSIP and generally used 
with connection-oriented networks. 


TP4 - An OSI transport protocol specified by GOSIP and generally used 
with connectionless networks such as CLNP. 


TREE - A tree is a set of points (vertices), and a set of directed lines 


(arcs); each arc leads from a vertex V to a vertex V'. The 
vertices V and V' are said to be the initial and final vertices of 
an arc a from V to V'. In a tree, several different arcs may have 


the same initial vertex, but not the same final vertex. 


UA — See USER AGENT. 


UAE - See USER AGENT ENTITY. 
UAL - See USER AGENT LAYER. 


USER - A person or computer application or process who makes use of a 
Message Handling System (MHS). 


USER AGENT - Typically, the User Agent (UA) is a set of computer 
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processes (for example, an editor, a file system, a word processor) 
that are used to create, inspect, and manage the storage of 
messages. There is typically one user per User Agent (UA). During 
message preparation, the originator communicates with his UA via an 
input/output (I/O) device (for example, a keyboard, display, 
printer, facsimile machine, and/or telephone). Also by means of 
these devices, the UA communicates to its user messages received 
from the Message Transfer System (MTS). To send and receive 
messages, the UA interacts with the MTS via the submission and 
delivery protocol. 


USER AGENT ENTITY - A User Agent Entity (UAE) is an entity in the User 
Agent Layer (UAL) of the Application Layer that controls the 
protocol associated with cooperating UAL services. It exchanges 
control information with the Message Transfer Agent Entity (MTAE) 
or the Submission and Delivery Entity (SDE) in the layer below. 
The control information is the information the Message Transfer 
layer (MTL) requires to create the appropriate envelope and thus 
provide the desired message transfer service elements. 


USER AGENT LAYER - The User Agent Layer (UAL) is the layer that contains 
the User Agent Entities (UAEs). 


X.25 - A packet switched network standard often used by public providers 
and optional in GOSIP. 


Appendix A: Current Activities in X.500 


NOTE: The following are edited excerpts from the IETF Directory 
Services Monthly reports as well as a few IETF scope documents. 
Effort has been taken to make sure this information is current as of 
late 1991. At the end of each section are lists of anonymous FTP 
and/or an e-mail address if more information is desired. 


IETF DISI 
(Directory Information Services Infrastructure Working Group) 


The Directory Information Services (pilot) Infrastructure Working 
Group is chartered to facilitate the deployment in the Internet of 
Directory Services based on implementations of the X.500 standards. 
It will facilitate this deployment by producing informational RFCs 
intended to serve as a Directory Services "Administrator's Guide". 
These RFCs will relate the current usage and scope of the X.500 
standard and Directory Services in North America and the world, and 
will contain information on the procurement, installation, and 
operation of various implementations of the X.500 standard. As the 
various implementations of the X.500 standard work equally well over 
TCP/IP and CLNP, the DISI working group shall not mandate specific 
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implementations or transport protocols. 


DISI is an offshoot of the OSI Directory Services group, and, 
accordingly, is a combined effort of the OSI Integration Area and 
User Services Area of the IETF. The current OSIDS working group was 
chartered to smooth out technical differences in information storage 
Schema and difficulties in the interoperability and coherence of 
various X.500 implementations. The DISI group is concerned solely 
with expanding the Directory Services infrastructure. As DISI will 
be providing information to facilitate the building of infrastructure 
with an eye towards truly operational status, DISI will need to form 
liaisons with COSINE, PARADISE, and perhaps the RARE WG3. 


As a final document, the DISI working group shall write a charter for 
a new working group concerned with user services, integration, 
maintenance and operations of Directory Services, the Operations and 
Infrastructure of Directory Services (OIDS) Group. 


One particular DISI document you may be interested in is a catalogue 
of the various X.500 implementations: 


Title : Catalog of Available X.500 Implementations 
Author(s) : R. Lang, R. Wright 

Filename : rfc1292.txt 

Pages : 103 


This document is available on the ESnet Information Server in the 
[ANONYMOUS.RFCS] directory. 


Mailing list address: 
General Discussion: disi@merit.edu 
To Subscribe: disi-request@merit.edu 
Anonymous FTP site address: (e-mail archive is here) 
merit.edu 


IETF OSI-DS (OSI Directory Service Working Group) 


The OSI-DS group works on issues relating to building an OSI 
Directory Service using X.500 and its deployment on the Internet. 
Whilst this group is not directly concerned with piloting, the focus 
is practical, and technical work needed as a pre-requisite to 
deployment of an open Directory will be considered. 


The major goal of this WG is to provide the technical framework for a 
Directory Service infrastructure on the Internet. This 
infrastructure should be based on the OSI Directory (X.500). It is 
intended that this infrastructure can be used by many applications. 
Whilst this WG is not directly concerned with operation of services, 


ESCC X.500/X.400 Task Force [Page 50] 


RFC 1330 X.500 and X.400 Plans for ESnet May 1992 
close liaison is expected with those groups which do operate pilots 
and services. 


Liaisons have been established with RARE WG3, NIST, CCITT/ISO IEC, 
North American Directory Forum. 


X.500 (1984) / ISO 9594 does not have sufficient functionality for 
full deployment on the Internet. This group identifies areas where 
extensions are required. 

It is a basic aim of the group to be aligned to appropriate base 
standards and functional standards. Any activity should be 
undertaken in the light of ongoing standardization activity. Areas 
which should be examined include: 

o Replication 

o Knowledge Representation 

o Schema Management 

o Access Control 

o Authentication 

o Distributed operations for partially connected DSAs 


o Presentation Address Handling 


Mailing list address: 
General Discussion: osi-ds@cs.ucl.ac.uk 


To Subscribe: osi-ds-request@cs.ucl.ac.uk 
Anonymous FTP site address: (all OSI-DS documents and e-mail archive 
cs.ucl.ac.uk are here) 


FOX (Field Operational X.500 Project) 


The FOX project is a DARPA funded effort to provide a basis for 
operational X.500 deployment in the NREN/Internet. This work is 
being carried out at Merit, NYSERnet/PSI, SRI and ISI. ISI is the 
main contractor and responsible for project oversight. 


There are two primary thrusts of the FOX project: 
1. X.500 Infrastructure: It is important that multiple 
interoperable platforms be available for deployment. FOX 


plans to examine and test the interoperability of the QUIPU 
and NIST-X.500 (Custos) implementations, and DNANS-X.500 if 
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possible. In addition, FOX will explore X.500 interfaces to 
conventional database systems (one target is Sybase), an 
alternate OS platform (VM) for X.500 servers, and X-window 
based user interfaces. 


2. X.500 Applications: A long-range goal is to facilitate the 
use of X.500 for real Internet applications. FOX will first 
focus on making network infrastructure information available 
through X.500. This includes network and AS site contacts, 
topology information, and the NIC WHOIS service. 


A centrally managed X.500 version will be the first phase of a WHOIS 
service. Providing an X.500 version of a well-known widely-used 
service should promote the use of X.500 by Internet users. In 
addition, this effort will provide experience in designing X.500 
applications. However, the manageability of this scheme will be 
short-lived, so the next step will be a design for a distributed 
version of WHOIS. 


Finally, it is critical for Internet X.500 efforts to be aligned with 
directory service efforts that are ongoing in other communities. FOX 
participants are involved in, or are otherwise tracking these 
efforts, and information about FOX activities will be publicly 
available. 


NADF (North American Directory Forum) 


The North American Directory Forum (NADF) is a collection of 
organizations which offer, or plan to offer, public Directory 
services in North America, based on the CCITT X.500 Recommendations. 


The NADF has produced a document, NADF-175, "A Naming Scheme for 
c=US", which has been issued as RFC-1255. 


The NADF-175 document proposes the use of existing civil 
infrastructure for naming objects under c-US. This has the advantage 
of using existing registration authorities and not establishing any 
new ones (the document simply maps names assigned by existing 
authorities into different portions of the c-US DIT). The document 
is intended as the basis for X.500 names in the U.S. for the long- 
term; it is important that interested parties get a copy, review it, 
and return comments. 


A second output, which is still undergoing development, is NADF-128, 
a preliminary draft on "Mapping the DIT onto Multiple ADDMDs". This 
describes how the c-US portion of the DIT is mapped onto DSAs and 
what service-providers must minimally share in order to achieve a 
working public directory. The next revision of this document will 
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likely be ASCII-ized and published as an informational RFC. 
NIST (National Institute of Standards and Technology) 


NIST is involved in several X.500 activities: standards, pilot 
deployment, and development of an X.500 implementation, Custos. The 
objective is to see X.500 widely deployed and used in the U.S. 
Government.  X.500 is expected to be in the next release of the U.S. 
Government OSI Profile (GOSIP). In the standards efforts, emphasis 
is on access control and replication; the other activities are 
described in some detail below. 


o NIST/GSA X.500 Pilot Deployment: NIST and GSA are 
collaborating in the creation of a U.S. Government X.500 pilot 
deployment. To date, two meetings have been held. At the 
second, held on April 25th at NIST, significant progress was 
made towards refining an initial draft schema developed by 
NIST. A number of government agency requirements will be 
included in the next schema revision. Once the schema is 
defined, agencies will begin collecting data for loading into 
the directory. Initially, NIST will offer to host agency data 
on Custos DSAs running at NIST. Eventually, agencies are 
expected to obtain and operate DSAs. 


o CUSTOS: The NIST X.500 public-domain implementation, Custos, 
is implemented on ISODE, although it otherwise bears no 
relation to QUIPU. One of its more interesting features is that 
the DBMS interface is SQL, and we provide a simple DBMS as part 
of Custos to support the DSA. Information can be optionally 
loaded into memory, and the memory usage is reasonably 
efficient on a per-entry basis. 


OIW (OSI Implementor's Workshop) 


The OSI Implementor's Workshop (OIW) is an open public forum for 
technical issues, concerned with the timely development of 
implementation agreements based on emerging international OSI 
standards. The Workshop accepts as input the specifications of 
emerging standards for protocols, and produces as output agreements 
on the implementation and testing particulars of these protocols. 
This process is expected to expedite the development of OSI protocols 
and to promote interoperability of independently manufactured data 
communications equipment. 


The Workshop organizes its work through Special Interest Groups 

(SIGs) that prepare technical documentation. The SIGs are encouraged 
to coordinate with standards organizations and user groups, and to 
seek widespread technical consensus on implementation agreements 
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through international discussions and liaison activities. 


The Directory SIG of the Workshop produces agreements on the 
implementation of Directory protocols based on ISO 9594 and CCITT 


X.500 Recommendations. There are three major areas that the SIG is 
working on for 1991: access control, replication, and distributed 
operations. 


Mailing list address: 
General Discussion: dssig@nisc.sri.com 
To Subscribe: dssig-request@nisc.sri.com 


PARADISE Project 


The PARADISE project is based at the Department of Computer Science, 
University College London (UCL). 


PARADISE is a sub-project of the broader COSINE project sponsored 
under the umbrella of EUREKA by eighteen participating countries and 
aimed at promoting OSI to the academic, industrial and governmental 
research and development organizations in Europe. The countries 
involved are those of the EC, EFTA plus Yugoslavia; that is: 

Austria, Belgium, Denmark, Finland, France, Germany, Greece, Holland, 
Ireland, Italy, Luxembourg, Norway, Portugal, Spain, Sweden, 
Switzerland, United Kingdom, and Yugoslavia. 


I 


The partners funded by PARADISE besides UCL are: 


o The Networks Group at the University of London Computer Centre 
(ULCC), which is a service-oriented organization providing a 
range of facilities to the academic community in London and the 
entry point into the UK for IXI, the COSINE international X.25 
backbone; 


o X-Tel Services Ltd, a software company based in Nottingham 
which currently provides service support to the UK Academic 
X.500 pilot; and 


o PTT Telematic Systems from the Netherlands, which in turn has 
subcontracted the Swiss and Finnish PTTs, and whose involvement 
is to create a forum for discussion on X.500 among the European 
carrier administrations. 


The project also aims to have representation from all the 
participating countries, which in the majority of cases are the 


existing X.500 national pilots. 


Of the 18 countries involved, at least 12 are registered in the White 
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Pages Pilot Project. Most countries are using the QUIPU 
implementation developed at UCL. However, a French group has 
developed PIZARRO, which will form the basis of the emerging French 


pilot. In Italy, a Torino-based company Systems Wizards are using 
DirWiz, which is currently the sole representative from Italy in the 
tree. 


Mailing list address: 
helpdesk@paradise.ulcc.ac.uk 


PSI White Pages Pilot Project 


The White Pages Pilot Project is the first production-quality field 
test of the OSI Directory (X.500). The pilot currently has a few 
hundred organizations (more each month) and is based on OSI TP4 over 
TCP/IP (RFC-1006). 


Anonymous FTP site address: (Most X.500 pilot project software is 
uu.psi.com here as well as more information) 


ANSI ASC X3T5.4 (Directory Ad Hoc Group) 


The American National Standards Institute (ANSI) Accredited Standards 
Committee (ASC) X3T5.4. This group reviews the Proposed Draft 
Amendments (PDAMs) for extensions to the International Consultative 
Committee for Telegraphy and Telephony (CCITT) X.500 
Recommendations/International Organization for Standardization 

(ISO) /International Electrotechnical Commission (IEC) 9594. 


Appendix B: Current Activities in X.400 


NOTE: The following are edited excerpts from the IETF X.400 Services 
Monthly reports as well as a few IETF scope documents. Effort has 
been taken to make sure this information is current as of February 
1992. At the end of each section are lists of anonymous FTP and/or 
an e-mail address if more information is desired. 


IETF OSIX400 (IETF OSI X.400 Working Group) 


The IETF OSI X.400 Working Group is chartered to identify and provide 
solutions for problems encountered when operating X.400 in a dual 
protocol internet. This charter includes pure X.400 operational 
issues as well as X.400 «-» RFC 822 gateway (ala RFC 987) issues. 


Mailing list address: 


General Discussion: ietf-osi-x400@cs.wisc.edu 
To Subscribe: ietf-osi-x400-requestücs.wisc.edu 
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IETF X4000PS (IETF X.400 Operations Working Group) 


X.400 management domains are being deployed today on the Internet. 
There is a need for coordination of the various efforts to insure 
that they can interoperate and collectively provide an Internet-wide 
X.400 message transfer service connected to the existing Internet 


mail service. The overall goal of this group is to insure 
interoperability between Internet X.400 management domains and to the 
existing Internet mail service. The specific task of this group is 


to produce a document that specifies the requirements and conventions 
of operational Internet PRMDs. 


Mailing list address: 
General Discussion: ietf-osi-x4000ps@pilot.cs.wisc.edu 
To Subscribe: ietf-osi-x4000ps-requestüpilot.cs.wisc.edu 


IETF MHS-DS (IETF Message Handling Services - Directory Services) 


The MHS-DS Group works on issues relating to Message Handling Service 
use of Directory Services. The Message Handling Services are 
primarily X.400, but issues relating to RFC 822 and RFC 822 
interworking, in as far as use of the Directory is concerned, are in 
the scope of the Group. Directory Services means the services based 
on X.500 as specified by the OSI-DS group (RFCs 1274, 1275, 1276, 
1277, 1278, 1297). The major aim of this group is to define a set of 
Specifications to enable effective large scale deployment of X.400. 
While this Group is not directly concerned with piloting, the focus 
is practical, and implementations of this work by members of the 
Group is expected. 


Mailing list address: 
General Discussion: mhs-ds@mercury.udev.cdc.com 
To Subscribe: mhs-ds-request(ümercury.udev.cdc.com 
Anonymous FTP site address: (e-mail archive is here) 
mercury.udev.cdc.com 


XNREN X.400 Pilot Project 


The Internet X.400 Project at the University of Wisconsin is funded 
by NSF. We are working on two main areas: 


1. Supporting the operational use of X.400. 


2. Working with others to define organizational procedures 
necessary to operate X.400 on a large scale in the Internet. 


To support the use of X.400, we are operating a PRMD, assisting sites 
in running PP or the Wisconsin Argo X.400 software packages, and 
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running an X.400 Message Transfer Agent (MTA) which is connected to 
U.S. and international MTAs using RFC1006/TCP/IP. Internet sites are 
invited to join our PRMD or establish X.400 connections with us. The 
organizational work is being done jointly by IETF working groups and 
RARE Working Group 1. 


Mailing list address: 
General Discussion:  x400-project-teamücs.wisc.edu 


I 


RARE WG1 (RARE Working Group 1 - Message Handling Systems) 


RARE (Reseaux Associes pour la Recherche Europeenne) Working Group 1, 
Message Handling Systems, creates and promotes a European 
infrastructure for a message handling service within the European 
research community, with connections to the global environment. 
Membership of the Working Group is by nomination from the national 
networking organizations, together with a number of invited experts. 


CCITT SG-D MHS-MD (CCITT Study Group D, MHS Management Domains) 


This group initially pursues the development of the rules for 
registering MHS management Domain names within the US. This group 
also pursues developing a set of voluntary agreements for North 
American operators of these management domains which will allow 


the US to uphold its Telecommunications treaty obligations 
while the industry maintains e-mail as an Information 
Processing service. The specific aspect of the treaty that is 


immediate concern to this group is that subscribers of MHS services 
in other countries, especially those countries who treat MHS as a 
Telecommunications service, must be able to reach MHS users in 
this country regardless of how their message enters the US and 
regardless of how many domains are involved in the transfer of the 
message to the intended recipient. 


The US State Department presently considers MHS (e-mail) as an 
Information Processing service. Some other countries consider any 
MHS (e-mail) service to be a Telecommunications service and 
hence, CCITT treaty obligations apply. 


NIST/GSA Interagency X.400 Connectivity Project 


The goal of this project is to assist the members of the Federal 
Information Resource Management Policy Council (FIRMPoC) in 
establishing electronic mail connectivity based on X.400. The 
outcome of this project is to continue, as the National Institute of 
Standards and Technology (NIST) has done in the past, providing 
Federal agencies with assistance in establishing electronic mail 
connectivity. This project is sponsored by the General Services 
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Administration (GSA). 


Appendix C: How to Obtain QUIPU, PP and ISODE 


ISODE/QUIPU 7.0 


This software supports the development of certain kinds of OSI 
protocols and applications. Here are the details: 


o 


ESCC X.500/X.400 Task Force 


The ISODE is not proprietary, but it is not in the public 
domain. This was necessary to include a "hold harmless" 
clause in the release. The upshot of all this is that anyone 
can get a copy of the release and do anything they want with 
it, but no one takes any responsibility whatsoever for any 
(mis)use. 


The ISODE runs on native Berkeley (4.2, 4.3) and AT&T System V 
systems, in addition to various other UNIX-like operating 
Systems. No kernel modifications are required. 


Current modules include: 


- OSI transport service (TPO on top of TCP, X.25 and CONS; 
TP4 for SunLink OST) 


- OSI session, presentation, and association control services 
- ASN.1 abstract syntax/transfer notation tools, including: 


1. Remote operations stub-generator (front-end for remote 
operations) 


2. Structure-generator (ASN.1 to C) 
3. Element-parser (basic encoding rules) 
- OSI reliable transfer and remote operations services 
- OSI directory services 
- OSI file transfer, access and management 
- FTAM/FTP gateway 
- OSI virtual terminal (basic class, TELNET profile) 


ISODE 7.0 consists of final "IS" level implementations with the 
exception of VT which is a DIS implementation. The ISODE also 
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contains implementations of the 1984 X.400 versions of ROS and 
RTS. 


o Although the ISODE is not "supported" per se, it does have a 
problem reporting address, Bug-ISODE@XTEL.CO.UK. Bug reports 
(and fixes) are welcome by the way. 


o The discussion group ISODE@NISC.SRI.COM is used as an open 
forum on ISODE. Contact ISODE-Request@NISC.SRI.COM to be added 
to this list. 


o The primary documentation for this release consists of a five 
volume User’s Manual (approx. 1000 pages) and a set of UNIX 
manual pages. The sources to the User’s Manual are in LaTeX 
format. In addition, there are a number of notes, papers, and 
presentations included in the documentation set, again in 
either LaTeX or SLiTeX format. If you do not have LaTeX, you 
should probably get a hardcopy from one of the distribution 
sites below. 


ISODE/QUIPU Distribution Sites 
The FTP or FTAM distributions of ISODE-7.0 consists of 3 files. The 


Source and main ISODE-7.0 distribution is in the file ISODE-7.tar.Z 
which is approximately 4.7MB in size. 


LaTeX source for the entire document set can be found in the ISODE- 
7-doc.tar.Z file (3.5MB). A list of documents can be found in the 
doc/ directory of the source tree. 


A Postscript version of the five volume manual can be found in the 
ISODE-7-ps.tar.Z file (4.3MB). 


If you can FTP to the Internet, then use anonymous FTP to uu.psi.com 
[136.161.128.3] to retrieve the files in BINARY mode from the ISODE/ 
directory. 


Additional PSI White Pages Pilot Software 
The 'usconfig' program configures a DSA which understands some of the 
NADF naming rules. This software is primarily intended for creating 
directory hierarchies for DSAs from scratch. The add-on software is 
available via anonymous FTP from uu.psi.com in: 


wp/src/wpp-addon.tar.Z 


Whether you choose to use 'usconfig' or not, please retrieve and 
install the addon, and follow the instructions therein. You might 


ESCC X.500/X.400 Task Force [Page 59] 


RFC 1330 X.500 and X.400 Plans for ESnet May 1992 
want to retrieve pilot-ps.tar.Z again also, as it contains an updated 
Administrator Guide. 

Note that the wpp-addon.tar.Z file needs to be installed on top of 
the ISODE 7.0 distribution; it does not duplicate any of the ISODE 
7.0, you need to retrieve and generate that too. 


PP 6.0 


PP is a Message Transfer Agent, intended for high volume message 


switching, protocol conversion, and format conversion. It is 
targeted for use in an operational environment, but is also be useful 
for investigating message related applications. Good management 


features are a major aspect of this system. PP supports the 1984 and 
1988 versions of the CCITT X.400 / ISO 10021 services and protocols. 
Many existing RFC-822 based protocols are supported, along with RFC- 
1148bis conversion to X.400. PP is an appropriate replacement for 
MMDF or Sendmail. This is the second public release of PP, and 
includes substantial changes based on feedback from using PP on many 
sites. 


o PP is not proprietary and can be used for any purpose. The only 
restriction is that suing of the authors for any damage the 
code may cause is not allowed. 


o PP runs on a range of UNIX and UNIX-like operating systems, 
including SUNOS, Ultrix, and BSD. A full list of platforms on 


which PP is know to run is included in the distribution. 


o Current modules include: 


X.400 (1984) P1 protocol. 


X.400 (1988) P1 protocol. 


- Simple mail transfer protocol (SMTP), conformant to host 
requirements. 


- JNT mail (grey book) Protocol. 
- UUCP mail transfer. 
- DECNET Mail-11 transfer 


- Distribution list expansion and maintenance, using either a 
file based mechanism or an X.500 directory. 


- RFC 822-based local delivery. 
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ESCC 


- Delivery time processing of messages. 


- Conversion between X.400 and RFC-822 according to the latest 
revision of RFC-1148, known as RFC-1148bis. 


- Conversion support for reformatting body parts and headers. 
- X-Window and line-based management console. 

- Message Authorization checking. 

- Reformatting support for "mail hub" operation. 


- X.500-based distribution list facility using the QUIPU 
directory. 


- FAX interworking 


No User Agents (UAs) are included with PP. However, procedural 
access to the MTA is documented, to encourage others to write 
or to port UAs. Several existing UAs, such as MH, may be used 
with PP. 


It is expected that a Message Store to be used in conjunction 
with PP (PPMS), and an associated X-Windows User Agent (XUA) 
will be released on beta test in first quarter 92. 


The core routing of PP 6.0 is table based. DNS is used by the 
SMTP channel. The next version of PP will support Directory 
Based routing, which may use X.500 or DNS. 


PP 6.0 requires ISODE 7.0. 


X-Windows release X11R4 (or greater) is needed by some of the 
management tools. PP can be operated without these tools. 


Although PP is not "supported" per se (but see later), it does 
have a problem reporting address (bug reports (and fixes) are 
welcome): 


RFC-822: PP-SUPPORT@CS.UCL.AC.UK 
X.400: S-PP-Support; OU-CS; O=UCL; 
PRMD-UK.AC; ADMD- ; C-GB; 


The discussion group PP-PEOPLE@CS.UCL.AC.UK is used as an open 


forum on PP; Contact PP-PEOPLE-REQUEST@CS.UCL.AC.UK to be added 
to this list. 
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o The primary documentation for this release consists of a three 
and a half volume User's Manual (approx. 300 pages) and a set 
of UNIX manual pages. The sources to the User's Manual are in 
LaTeX format. 


PP Distribution Sites 


If you can FTP to the Internet from outside Europe, then use 
anonymous FTP to uu.psi.com [136.161.128.3] to retrieve the file pp- 
6.tar.Z in binary mode from the ISODE/ directory. This file is the 
tar image after being run through the compress program and is 
approximately 3Mb in size. 


If you can FTP to the Internet from Europe, then use anonymous FTP to 
archive.eu.net [192.16.202.1] to retrieve the file pp-6.tar.Z in 
binary mode from the network/ISODE/ directory. This file is the tar 
image after being run through the compress program and is 
approximately 3Mb in size. 


ISODE/QUIPU and PP Platforms as of December 1991 


Machine OS ISODE PP Stacks Notes 
CCUR 6000 RTU 5.0 7.0 Yes! TCP 1 
CCUR 6000 RTU 6.0 7.0 Yes! TCP 2 
X25 
CLNS 
CDC 4000 Series EP/IX 1.3.2 6.64 TCP 3 
EP/IX 1.4.1 CLNS 
X25 
COMPAQ 386/25 SCO Unix 5.2 6.0 TCP 
COMPAQ 386 BSD 7.0 TCP 4 
X25 
Convex C120 ConvexOS 8.1 7.0 TCP 5 
DEC Vax 2nd Berkeley Network rel 7.0 TCP 
X25 
DEC DECnet-ULTRIX V5.0 7.0 TCP 6 
CLNS 
DEC Ultrix 3.1D 7.0 5.2 TCP F 
Ultrix 4.0 X25 
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Multimax 3xx UMAX V 2.2h 
Multimax 5xx 


Encore 


Encore 
Encore 


PN6000 
PN9000 


HP/UX 6.0 
HP-UX 7.05 B 
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Pyramid 9800 OSx 5.1 (4.3BSD/SVR3.2) 7.0 5A TCP 18 
Pyramid MIS 

SEQUENT DYNIX V3.0.18 BO TCP 8 
Sony News-1750 NEWS-OS 3.3 6.8 TCP 


NEWS-OS 4.0c 


Sun4 SunOS 4.1 7.0 5.2 TCP 
Sun3 SunOS 4.1.1 X25 
SunOS 4.0.3c CONS 
CLNS 

Notes: 


1. NOT SNMP or VT 

2. Little tested 

3. Official upper layer 

4. Prototype only! 

5. Planned port 

6. Being worked on! 

7. 3.1D binaries compiled under 4.2 
8. Only QUIPU confirmed 

9. Not QUIPU 

10. Need "-Dregister-" in CONFIG.make 


11. Need bug-fix no. 5 from bug-ISODEGxtel.co.uk. not SNMP,VT or 
FTAM-FTP gateway 


12. No VT, QUIPU not tested 
13. Models 80 and 95 


14. NOT SNMP or VT,PP and X.25 requires patches available from 
X-Tel 


15. Using MacTCP 
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16. Only QUIPU tested, built using BSD43 config 
17. Need bug-fix no. 6 from bug-ISODEGxtel.co.uk 
18. Built using BSD config, no VT or SNMP 


The above tables do not refer to beta releases of ISODE and PP more 
recent than the public ISODE-7.0 or PP-5.2 releases. The above table 
is generated from reports sent to bug-ISODE and pp-support. There is 
no guarantee the information is correct. 


Appendix D: Sample X.500 Input File and Restricted Character List 


Below is a sample datafile that illustrates the format for providing 
data about persons at your site to be loaded into the ESnet DSA. 
Following the sample datafile is a detailed explanation of the format 
and content of the file. We have tried to be as flexible as possible 
in defining the format of the file, given the constraints imposed by 
an automated process. We would appreciate feedback on the format of 
the file and will try to accommodate any specific needs you may have 
to any extent that is reasonable. 


# 

# Sample Data File for Bulk Loading X.500 Database 

# 

# delimiter character is "," 1 
# field 1 is commonName 2 
# field 2 is phone extension 3 
# area code for all numbers is 510 4 
# prefix for all numbers is 422 5 
# field 3 is rfc822Mailbox 6 
# field 4 is facsimileTelephoneNumber 7 
# default facsimileTelephoneNumber is (510) 422-3333 8 
# postalAddress for all entries is: 9 
# National Energy Research Supercomputer Center 10 
# P.O. Box 5509 11 
# Livermore, California 94552 12 
# 

Chris Anderson, 1915,anderson@wsl.nersc.gov, 13 
Lila Brown, 5680,brownl@ws2.nersc.gov, 14 
Bob Green, 4474,, 15 
Max Jones, 4488,elvis@presley.nersc.gov, 5104224444 16 
Dave Smith, 9818, smithd@ws3.nersc.gov, As? 
Cathy White, 4016, snow@white.nersc.gov, 18 


«end-of-file» 


Comment lines at the beginning of the file convey relevant formatting 
information. 
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Following comment lines, each data line contains information about 
one person. 


Fields within a single data line are separated by a delimiter 
character. You specify the delimiter character you wish to use in 
the comment section; be sure to choose a delimiter which does not 
appear as a legitimate character in any field of a data line. 


You may provide all or part of the attribute types listed in the 
table in Section 2.5 (commonName is required). In the comment 
section, you must indicate which attribute types are contained in 
each field of a data line. 


Each data line must contain the same number of fields and the same 


order of fields (i.e. same order of attribute types). Two successive 
delimiters indicated a null value (eof is a considered a field 
delimiter). 

The characters "=", "&", "$", and "4" are NEVER allowed in any 


attribute value. 


Below is a discussion of relevant lines of the sample datafile. 


Line 1 The delimiter character is identified as a comma (,). 

Line 2 Field 4 1 is identified as containing the commonName 
attribute. 

Line 3 Field 4 2 is identified as containing the telephoneNumber 
attribute. The actual data value is a 4-digit 
extension. 


Lines 4,5 Identify the area code and prefix which apply to all 
4-digit extensions in the datafile. If your actual 
data values already contain area code and/or prefix, 
then there would be no need to indicate default values. 


Line 6 Field 4 3 is identified as containing the rfc822Mailbox 
attribute. 
Line 7 Field 4 4 is identified as containing the 


facsimileTelephoneNumber attribute. 
Line 8 Identifies the default value for 
facsimileTelephoneNumber. If field 4 is missing in a 


data line, the default value will be applied. 


Lines 9-12 Identify the value of the postalAddress attribute which 
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applies to all entries. 


Line 13 commonName= Chris Anderson 

surName- Anderson 

telephoneNumber= 510-422-1915 

rfc822MailBox- anderson@wsl.nersc.gov 

facsimileTelephoneNumber- 510-422-3333 

postalAddress- National Energy Research Supercomputer Center 
P.O. Box 5509 
Livermore, California 94552 


Line 14 commonName= Lila Brown 

surName= Brown 

telephoneNumber= 510-422-5680 

rfc822MailBox= brownl@ws2.nersc.gov 

facsimileTelephoneNumber= 510-422-3333 

postalAddress= National Energy Research Supercomputer Center 
P.O. Box 5509 
Livermore, California 94552 


Line 15 commonName= Bob Green 

surName= Green 

telephoneNumber= 510-422-4474 

rfc822MailBox- 

facsimileTelephoneNumber- 510-422-3333 

postalAddress- National Energy Research Supercomputer Center 
P.O. Box 5509 
Livermore, California 94552 


Line 16 commonName= Max Jones 

surName- Jones 

telephoneNumber- 510-422-4488 

rfc822MailBox- elvis@presley.nersc.gov 

facsimileTelephoneNumber- 510-422-4444 

postalAddress- National Energy Research Supercomputer Center 
P.O. Box 5509 
Livermore, California 94552 


Line 17  commonName- Dave Smith 

surName- Smith 

telephoneNumber- 510-422-9818 

rfc822MailBox- smithd@ws3.nersc.gov 

facsimileTelephoneNumber- 510-422-3333 

postalAddress- National Energy Research Supercomputer Center 
P.O. Box 5509 
Livermore, California 94552 
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Line 18 commonName= Cathy White 

surName- White 

telephoneNumber- 510-422-4016 

rfc822MailBox- snow@white.nersc.gov 

facsimileTelephoneNumber- 510-422-3333 

postalAddress- National Energy Research Supercomputer Center 
P.O. Box 5509 
Livermore, California 94552 


Appendix E:  ESnet Backbone Sites 
Government Agencies 


U.S. Department of Energy, Office of Energy Research (DOE) 
Germantown, Maryland USA 


U.S. Department of Energy, San Francisco Office (SAN) 
Oakland, California USA 


National Laboratories 


NASA Ames Research Center (AMES, FIX-WEST) 
Mountain View, California USA 


Argonne National Laboratory (ANL) 
Argonne, Illinois USA 


Brookhaven National Laboratory (BNL) 
Upton, New York USA 


Continuous Electron Beam Accelerator Facility (CEBAF) 
Newport News, Virginia USA 


Fermi National Accelerator Laboratory (FNAL) 
Batavia, Illinois USA 


Lawrence Berkeley Laboratory (LBL) 
Berkeley, California USA 


Lawrence Livermore National Laboratory (LLNL) 
Livermore, California USA 


Los Alamos National Laboratory (LANL) 
Los Alamos, New Mexico USA 


Oak Ridge National Laboratory (ORNL) 
Oak Ridge, Tennessee USA 
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Pacific Northwest Laboratory (PNL) 
Richland, Washington USA 


Princeton Plasma Physics Laboratory (PPPL) 
Princeton, New Jersey USA 


Sandia National Laboratory, Albuquerque (SNLA) 
Albuquerque, New Mexico USA 


Stanford Linear Accelerator Center (SLAC) 
Menlo Park, California USA 


Superconducting Super Collider (SSC) 
Dallas, Texas USA 


Universities 


California Institute of Technology (CIT) 
Pasadena, California USA 


Florida State University (FSU) 
Tallahassee, Florida USA 


Iowa State University (ISU) 
Ames, Iowa USA 


Massachusetts Institute of Technology (MIT) 
Cambridge, Massachusetts USA 


New York University (NYU) 
Upton, New York USA 


Oak Ridge Associated Universities (ORAU) 
Oak Ridge, Tennessee USA 


University of California, Los Angeles (UCLA) 
Westwood, California USA 


University of Maryland (UMD, FIX-EAST) 
College Park, Maryland USA 


University of Texas, Austin (UTA) 
Austin, Texas USA 


Commercial Entities 


General Atomics (GA) 
San Diego, California USA 
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Office of Science and Technology Information (OSTI) 
Oak Ridge, Tennessee USA 


Science Applications, Incorporated (SAIC) 
McLean, Virginia USA 


Appendix F: Local Site Contacts for DOE Naming Authorities 


Below is a list of all Department of Energy GOSIP Site Authorities 
for OSI registration and addressing. This information was obtained 
from the DoE GOSIP On-Line Information System (DOE-GOIS), dated 
November 18, 1991. 


Marian F. Sotel 

Director, Information management Division 
U.S. Department of Energy 

DOE Field Office, Albuquerque 


Dennis Jensen 

Ames Laboratory 
258H Development 
Ames, IA 50011-3020 
(515) 294-7909 


Linda Winkler 

Argonne National Laboratory 
Argonne, IL 60439 

(708) 972-7236 


R. E. Kremer 

Manager, Resource Automation 
U.S. Department of Energy 
Bettis Atomic Power laboratory 


Gary Ragsdale 

Manager, Information Services 
U.S. Department of Energy 
Bonneville Power Administration 
905 NE 11th Avenue 

Portland, OR 97232 


Wayne Larson 

Head of Data Communications Unit 
U.S. Department of Energy 
Bonneville Power Administration 
905 NE 11th Avenue 

Portland, OR 97232 
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George Rabinowitz 

Head Distributed Computing Section 
Brookhaven National Laboratory 
Upton, New York 11973 

(516) 282-7637 


Donna A. Dyxin 
Communications Specialist 
U.S. Department of Energy 
DOE Field Office, Chicago 
9800 South Cass Avenue 
Argonne, IL 60439 


Elaine R. Liebrecht 

System Manager and Planning Supervisor 
EG&G Mound Applied Technologies 

P.O. Box 3000 

Miamisburg, OH 45343-3000 

(FTS) 774-3733 or (513) 865-3733 


Jeffrey J. Johnson 
Communications Supervisor 

EG&G Mound Applied Technologies 
P.O. Box 3000 

Miamisburg, OH 45343-3000 

(FTS) 774-4230 or (513) 865-4230 


Paul P. Herr 

U.S. Department of Energy 
Energy Information Agency 
(202) 586-7318 


William H. Foster 

U.S. Department of Energy 
Energy Information Agency 
(202) 586-6310 


Mark O. Kaletka 

Data Communications Group Leader, Computing Div. 
Fermi National Accelerator Lab 

P.O. Box 500 

Batavia, IL 60510 

(708) 840-2965 


David A. Mackler 


Grand Junction Project Office 
(FTS) 326-6412 
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Wayne L. Selfors 
Grand Junction Project Office 
(FTS) 326-6525 


Gerald F. Chappell 

Director, ITSO 

U.S. Department of Energy 
Headquarters 

Washington D.C., 20545 

(FTS) 233-3685 or (301) 903-3685 


Joe Diel 
Supervisor, Biomathematics Group 
ITRI 


David H. Robinson 

Section Supervisor, Information Systems 
Allied-Signal Aerospace Company 

Kansas City Division 

P.O. Box 419159 

Kansas City, MO 64141-6159 

(FTS) 997-3690 or (816) 997-3690 


Robert M. Jensen 

Supervisory Engineer, Information Systems 
Allied-Signal Aerospace Company 

Kansas City Division 

P.O. Box 419159 

Kansas City, MO 64141-6159 

(FTS) 997-5538 or (816) 997-5538 


Russell Wright 

Lawrence Berkeley Laboratories 
1 Cyclotron Road 

Berkeley, CA 94720 

(510) 486-6965 


William A. Lokke 

Associate Director for Computation 
Lawrence Livermore National Lab 
(FTS) 532-9870 or (669) 422-9870 


Philip Wood/Glenn Michel 

Los Alamos National Laboratory 
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Appendix G: Recommended Reading 
RFCs (Request For Comments) 


The following RFCs may be obtained from the ESnet Information Server. 
They are stored in the directory [ANONYMOUS.RFCS]. They may be 
retrieved via anonymous FTP (nic.es.net, 128.55.32.3) or DECnet copy 
(ESNIC::, 41.174). 


RFC1328 X.400 1988 to 1984 downgrading.  Hardcastle-Kille, S.E. 1992 
May; 5 p. (Format: TXT-10006 bytes) 


RFC1327 Mapping Between X.400 (1988) /ISO 10021 and RFC 822. 
Hardcastle-Kille, S.E. 1992 May; 113 p. (Format: TXT-228598 bytes) 


RFC1309 Technical overview of directory services using the X.500 
protocol. Weider, C.; Reynolds, J.K.; Heker, S. 1992 March; 4 p. 
(Format: TXT=35694 bytes) 


RFC1308 Executive Introduction to Directory Services Using the X.500 
Protocol. Weider, C.; Reynolds, J.K. 1992 March; 4 p. (Format: 
TXT=9392 bytes) 


RFC1295 North American Directory Forum. User bill of rights for 
entries and listing in the public directory. 1992 January; 2 p. 
(Format: TXT=3502 bytes) 


RFC1292 Lang, R.; Wright, R. Catalog of Available X.500 
Implementations. 1991 December; 103 p. (Format: TXT=129468 bytes) 


RFC1279 Hardcastle-Kille, S.E. X.500 and domains. 1991 November; 13 
p. (Format: TXT=26669, PS-170029 bytes) 


RFC1278 Hardcastle-Kille, S.E. String encoding of presentation 
address. 1991 November; 5 p. (Format: TXT=10256, PS=128696 bytes) 


RFC1277 Hardcastle-Kille, S.E. Encoding network addresses to support 
operations over non-OSI lower layers. 1991 November; 10 p. 
(Format: TXT=22254, PS=176169 bytes) 


RFC1276 Hardcastle-Kille, S.E. Replication and distributed operations 
extensions to provide an Internet directory using X.500. 1991 
November; 17 p. (Format: TXT=33731, PS=217170 bytes) 


RFC1275 Hardcastle-Kille, S.E. Replication requirements to provide an 


Internet directory using X.500. 1991 November; 2 p. (Format: 
TXT=4616, PS=83736 bytes) 
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RFC1274 Kille, S.E.; Barker, P. COSINE and Internet X.500 schema. 1991 
November; 60 p. (Format: TXT-92827 bytes) 


RFC1255 North American Directory Forum. Naming scheme for c-US. 1991 
September; 25 p. (Format: TXT-53783 bytes) (Obsoletes RFC 1218) 


RFC1249 Howes, T.; Smith, M.; Beecher, B. DIXIE protocol 
specification. 1991 August; 10 p. (Format: TXT=20693 bytes) 


RFC1202 Rose, M.T. Directory Assistance service. 1991 February; 11 p. 
(Format: TXT=21645 bytes) 


RFC1006 Rose, M.T.; Cass, D.E. ISO transport services on top of the 
TCP: Version 3. 1987 May; 17 p. (Format: TXT=31935 bytes) 


Non Published Working Notes 


"A String Representation of Distinguished Names", S.E. Hardcastle-Kille, 
01/30/1992. 


The OSI Directory uses distinguished names as the primary keys to 
entries in the directory. Distinguished Names are encoded in 
ASN.1. When a distinguished name is communicated between to users 
not using a directory protocol (e.g., in a mail message), there is 
a need to have a user-oriented string representation of 
distinguished name. 


"An Access Control Approach for Searching and Listing", S.E. 
Hardcastle-Kille, T. Howes, 09/23/1991. 


This memo defines an extended ACL (Access Control List) mechanism 
for the OSI Directory. It is intended to meet strong operational 
requirements to restrict searching and listing externally, while 
allowing much more freedom within an organization. In particular, 
this mechanism makes it possible to restrict searches to certain 
sets of attributes, and to prevent "trawling": the disclosure of 
large organizational data or structure information by repeated 
searches or lists. This capability is necessary for organizations 
that want to hide their internal structure, or to prevent dumping 


of their entire database. This memo describes functionality 
beyond, but compatible with, that expected in the 1992 X.500 
standard. 


"Building an Internet Directory using X.500", S. Kille, 01/07/1991. 
The IETF has established a Working Group on OSI Directory Services. 


A major component of the initial work of this group is to establish 
a technical framework for establishing a Directory Service on the 
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Internet, making use of the X.500 protocols and services. This 
document summarizes the strategy established by the Working Group, 
and describes a number of RFCs which will be written in order to 
establish the technical framework. 


"Directory Requirements for COSINE and Internet Pilots (OSI-DS 18)", 
S.E. Hardcastle-Kille, 07/09/1991. 


This document specifies operational requirements for DUAs and DSAs 
in the Internet and COSINE communities. This document summarizes 
conformance requirements. In most cases, technical detail is 
handled by reference to other documents. This document refers to 
core directory infrastructure. Each application using the directory 
may impose additional requirements. 


"DSA Naming", S.E. Hardcastle-Kille, 01/24/1992. 


This document describes a few problems with DSA Naming as currently 
deployed in pilot exercises, and suggests a new approach. This 
approach is suggested for use in the Internet Directory Pilot, 
which overcomes a number of existing problems, and is an important 
component for the next stage in increase of scale. 


"Handling QOS (Quality of service) in the Directory", S.E. Kille, 
08/29/1991. 


This document describes a mechanism for specifying the Quality of 
Service for DSA Operations and Data in the Internet Pilot Directory 
Service "Building and internet directory using X.500". 


"Interim Directory Tree Structure for Network Infrastructure 
Information", Chris Weider, Mark Knopper, Ruth Lang, 06/14/1991. 


As work progresses on incorporating WHOIS and Network 
Infrastructure information into X.500, we thought it would be 
useful to document the current DIT structure for this information, 
along with some thoughts on future expansion and organization of 
this subtree of the DIT. The first section of this document 
describes the current structure, the second section the possible 
expansion of the structure. 


"Interim Schema for Network Infrastructure Information in X.500 New 
name: Encoding Network Addresses to support operation ov", Chris 
Weider, Mark Knopper, 06/14/1991. 


As the OSI Directory progresses into an operational structure which 
is being increasingly used as a primary resource for Directory 
Information, it was perceived that having the Internet Site 
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Contacts and some limited network information in the Directory 
would be immediately useful and would also provide the preliminary 
framework for some distributed NIC functions. This paper describes 
the interim schema used to contain this information. 


"Naming Guidelines for Directory Pilots", P. Barker, S.E. Kille, 


"OSI 


01/30/1992. 


Deployment of a Directory will benefit from following certain 
guidelines. This document defines a number of naming guidelines. 
Alignment to these guidelines will be recommended for national 
pilots. 


NSAP Address Format For Use In The Internet", R Colella, R Callon, 
02/13/1991. 


The Internet is moving towards a multi-protocol environment that 
includes OSI. To support OSI, it is necessary to address network 
layer entities and network service users. The basic principles of 
OSI Network Layer addressing and Network Service Access Points 
(NSAPs) are defined in Addendum 2 to the OSI Network service 
definition. This document recommends a structure for the Domain 
Specific Part of NSAP addresses for use in the Internet that is 
consistent with these principles. 


"Representing Public Archives in the Directory", Wengyik Yeong, 


12/04/1991. 


The proliferation of publicly accessible archives in the Internet 
has created an ever-widening gap between the fact of the existence 
of such archives, and knowledge about the existence and contents of 
these archives in the user community. Related to this problem is 
the problem of also providing users with the necessary information 
on the mechanisms available to retrieve such archives. In order 
for the Internet user community to better avail themselves of this 
class of resources, there is a need for these gaps in knowledge to 
be bridged. 


"Schema for Information Resource Description in X.500", Chris Weider, 


06/14/1991. 


The authors are interested in allowing distributed access and 
updating for Information Resource Description information to users 
of the Internet. This paper discusses the schema used to hold the 
Information Resource Description information. The new attributes 
are taken from the US-MARC fields, and subfields, with the mapping 
described in the text. 
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"Schema for NIC Profile Information in X.500", Chris Weider, Mark 
Knopper, 06/14/1991. 


The authors of this document, in conjunction with the chairs of the 
IETF Network Information Services Infrastructure (NISI) group, 
would like to implement a Directory of Network Information Centers, 
or NICs. This will enable NICs to find each other easily, will 
allow users with access to a DSA to find out where NICs are, and 
will in general facilitate the distribution of information about 
the Internet and some of its infrastructure. This document 
proposes a set of standard schema for this information. 


"Using the OSI Directory to Achieve User Friendly Naming", S. Kille, 
01/30/1992. 


The OSI Directory has user friendly naming as a goal. A simple 
minded usage of the directory does not achieve this. Two aspects 
not achieved are: 1) A user oriented notation and 2) 
Guessability. This proposal sets out some conventions for 
representing names in a friendly manner, and shows how this can be 
used to achieve really friendly naming. This then leads to a 
Specification of a standard format for representing names, and to 
procedures to resolve them. This leads to a specification which 
allows directory names to be communicated between humans. The 
format in this specification is identical to that defined in the 
reference of "A String Representation of Distinguished Name", and 
it is intended that these specifications are compatible. 


"Requirements for X.400 Management Domains (MDs) Operating in the Global 
Research and Development X.400 Service", R. Hagens, 11/12/1991. 


This document specifies a set of minimal operational 
requirements that must be implemented by all Management Domains 
(MDs) in the Global R&D X.400 Service. This document defines 
the core operational requirements; in some cases, technical 
detail is handled by reference to other documents. The Global 
R&D X.400 Service is defined as all organizations which meet the 
requirements described in this document. 


"Routing Coordination for X.400 MHS Services within a 
Multiprotocol/Multinetwork Environment", U. Eppenberger, 
10/25/1992. 


The X.400 addresses do start to appear on business cards. The 
different MHS service providers are not well interconnected and 
coordinated which makes it a very hard job for the MHS managers to 
know where to route all the new addresses. A big number of X.400 
implementations support different lower layer stacks. Taking into 
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account the variety of existing large transport networks, there is 
now the chance of implementing a worldwide message handling service 
using the same electronic mail standard and therefore without the 
need of gateways with service reduction and without the restriction 
to a single common transport network. This document proposes how 
messages can travel over different networks by using multi stack 
MTAs as relays. Document formats and coordination procedures bridge 
the gap until an X.500 directory service is ready to store the 
needed connectivity and routing information. 


International Standards Documents 


International Consultative Committee for Telephone and Telegraph. Open 
Systems Interconnection - The Directory. X.500 Series 
Recommendations. December, 1988. 


(also published as) 


ISO/IEC. Information Technology - Open Systems Interconnection - The 
Directory. International Standard 9594. 1989. 


International Consultative Committee for Telephone and Telegraph. Data 
Communication Networks - Message Handling Systems. X.400 Series 
Recommendations. Geneva 1985. 


International Consultative Committee for Telephone and Telegraph. Data 
Communication Networks - Message Handling Systems. X.400 Series 
Recommendations. Melbourne, 1988. 


NIST Documents 
(National Institute of Standards and Technology Documents) 


The following documents can be retrieved from the ESnet Information 
Server in directory [ANONYMOUS.NIST]. 


Government Open Systems Interconnection Profile (GOSIP) Version 1, 
National Institute of Standards and Technology, Federal Information 


Processing Standards Publication #146, August, 1988. 


Government Open Systems Interconnection Profile (GOSIP) Version 2, 
National Institute of Standards and Technology, October, 1990. 


DOE Documents 
The following documents prepared by the DOE GOSIP Migration Working 


Group can be retrieved from the ESnet Information Server in directory 
[ANONYMOUS.DOE-GOSIP]. 
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U.S. Department of Energy. Government Open Systems Interconnection 
Profile. Transition Strategy. DOE GOSIP Document # GW-ST-008. 
November, 1990. 


U.S. Department of Energy. Government Open Systems Interconnection 
Profile. Transition Plan. DOE GOSIP Document 4 GW PN 005. 
November, 1990. 


U.S. Department of Energy. Government Open Systems Interconnection 
Profile. Procedures and Guidelines. DOE GOSIP Document 4 GW-PR- 
007. April, 1991. 


IETF Working Groups 


Three IETF working groups, OSI X.400, OSI-DS and MHS-DS have been 
working in in X.400 and X.500. Minutes of meetings, descriptions of 
the working groups' charters and goals, information about mailing 
lists, and other pertinent documents can be retrieved from the ESnet 
Information Server in the directories [ANONYMOUS.IETF.OSIDS], 
[ANONYMOUS.IETF.OSIX400] and [ANONYMOUS.IETF.MHSMS]. 


Others 
Marshall T. Rose, Julian P. Onions and Colin J. Robbins. The ISO 
Development Environment: User's Manual, 1991.  ISODE Documentation 


Set. 


Marshall T. Rose and Wengyik Yeong. PSI White Pages Pilot Project: 
Administrator’s Guide, 1991. 3 ISODE Documentation Set. 


Marshall T. Rose. The Open Book: A Practical Perspective on Open 
Systems Interconnection. Prentice-hall, 1990. ISBN 0-13-643016-3. 


Marshall T. Rose. The Little Black Book: Mail Bonding with OSI 
Directory Services. Prentice-hall, 1991. ISBN 0-13-683219-5. 


Alan Turner and Paul Gjefle, Pacfic Northwest Laboratory. Performance 
Analysis of an OSI X.500 (QUIPU) Directory Service Implmentation. 
1992. Available on nic.es.net in the directory [ANONYMOUS.ESNET- 
DOC]QUIPU-PERF.PS 
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Security Considerations 


Security issues are discussed in sections 2.5.1 and 2.7.5.1 of this 
memo. 
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